At 10:45 AM -0700 4/20/06, David Graham wrote:
I have read several explanations of why DoEvents are to be avoided in GUI applications, but I remain confused. Someday maybe I will have time to figure out how to program a thread, but in the meantime...
Oh, pooh -- you could have learned how to program a REALbasic thread in less time than it took to type that message. :) There's nothing to it:
1. Create a Thread object someplace that you can conveniently implement its Run event. Adding one to a window is often a good way; else use a subclass.
2. Stick the code that you want to run in a thread in the thread's Run event. (This could be a one-line call to the method that was previously running NOT in a thread, if you like.)
3. Where you previously called the not-in-a-thread method, call Thread.Run instead.
That's it; there's no step 4.
But if the only way to get into the method that runs this calculation is with a command button that was disabled when the method was called, and not re-enabled again until the method was finished, how could this DoEvents cause any trouble?
Nobody's saying that you can't sometimes call DoEvents without shooting yourself in the foot. You can sometimes juggle gas-filled tennis balls over an open barbecue pit without getting into trouble, too. But I wouldn't recommend it.
Best, - Joe -- Joseph J. Strout [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
