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

HTH

David



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.
>
>
>     PreloadSong;
>
>     WaitForEngine; // does a LoopSleep
>
>     SetCuePosition;
>
>     WaitForEngine;
>
>     StartPlay;
>
>     etc.
>
>
> 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.
>
> At least, that's the way I'd tackle this problem.
>
> :)
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi@list...
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request@list... with Subject: unsubscribe