On Aug 21, 2006, at 6:18 PM, Charles Yeomans wrote:
I think you're using it incorrectly. The better practice for
thread + GUI is to use a timer to periodically have the GUI ask the
thread for current information.
There are times when a Timer does not fire, such as when you have
returned True in a Control.MouseDown() event. In cases like this, I
have found that a tight loop in a thread is a better substitute, but
the last time I needed to do something like this the Thread.Sleep()
option was not yet available.
That said, I have refactored the code to use a Timer, and it works
well enough for me right now (better than I expected).
Jon Johnson has a good explanation of this somewhere on his
nilobject.com site.
I saw his ProgressThread, but that is not the same as what I need.
-------
But back to the main point... I think that the Thread Manager
implementation is flawed (at least on OS X which is the only platform
I tested). It does not make any sense that once you call Sleep() on
a thread, it forces the CPU to peg at 100%. It is as if REALbasic is
going into an tight loop waiting for the thread to wake up again.
_______________________________________________
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>
