Article Preview
Buy Now
| Print: | |
| PDF: |
Object-Oriented Thinking
A Simple Threaded Application
Threads Keep The UI Responsive
Issue: 5.4 (May/June 2007)
Author: Charles Yeomans
Article Description: No description available.
Article Length (in bytes): 4,396
Starting Page Number: 41
RBD Number: 5415
Resource File(s):
5415.zip Updated: Friday, May 18, 2007 at 10:50 AM
Related Web Link(s):
http://www.declareSub.com/
http://www.nilobject.com/2005/12/08/holiday-treat/
Known Limitations: None
Excerpt of article text...
Long-running methods can prevent the user interface from being updated. This is an annoyance for user, and thus a problem for many developers. The solution is simple enough: execute such methods in a separate thread.
Unfortunately, some developers attempt to take what appears to be the easy way out by calling App.DoEvents to cycle the event loop. This can lead to serious problems with unexpected reentrancy. If you don't know why this is dangerous, then you surely should not be calling DoEvents. If you think you do, then you can use DoEvents, since it is a documented method. But don't expect any sympathy from the Real Software engineers if you encounter problems.
And, assuming that you "know what you're doing," there remains the problem of calling App.DoEvents. Presumably you would call it from within the long-running method. This entangles the method implementation with the user interface, assuming that you can do this -- perhaps you're using an encrypted class.
Instead, use a thread to execute the long-running method. The recipe is this. First, the long-running method code does not talk to the user interface. Second, execute the method from a Thread object. Third, use a Timer to check the execution state of the method and update the UI as needed.
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
