You may also want to take a look at the PostThreadMessage API, which you can
use to signal from a thread back to the main thread or vice versa
On 15/05/12 18:53, Jolyon Smith wrote:
Do your UI updates on the main thread and find some other way of
communicating what the UI thread needs to update itself. i.e. decouple your
UI from the data it visualises.
WaitForEngine; // does a LoopSleep
Do this in a worker thread then your UI can continue to update on the main
thread without having to worry about anything else. You're right that the
VCL isn't thread safe, but it's easier to make your data sources thread safe
so that the VCL main thread can access them safely along with any worker
threads, than it is to try to make the main VCL thread behave as if it were
effectively multiple threads (which is what you are trying to do by having
it do work, update the UI AND pump the message queue).
Also, the fact that your routine is called "WaitForEngine" suggests to me
that an event would be ideal in your situation. If accurately named, that
routine indicates that your worker thread is waiting for some signal that
the engine is ready, a signal that the engine can send directly using an
event (i.e. a TEvent - a thread synchronisation object, not a TNotifyEvent
or similar), rather than using a busy-wait loop.
It may not be a solution as quick and easy as throwing in a call to
Application.ProcessMessages, but I am pretty confident that it will
absolutely be more robust in the long run.