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: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
