2010/1/21 Brad Campbell <[email protected]>: > Yeah, but what I'm trying to do is have the main gui thread sit on its hands > until it has a message waiting for it. Then I'd like to have it wakeup on an > event rather than spinning or polling, while still remaining responsive to > user input.
Polling is the only way to check for messages. If you block the main thread waiting for an event your application will be unresponsive; it needs to be in a constant loop. The async queue is checked every iteration so eventually your callback will be called. > Unless I'm mistaken (and I'm pretty green at thread stuff still) it looks > like you are running a separate thread that checks a message queue and runs > the callbacks from there, so you are possibly updating gui components from a > thread other than the main thread. Is that kosher? No, the callbacks are run from CallMethods() which is called via Synchronize(), so they are run from the main thread. But instead of the thread that queued the callback being blocked it is the thread from GuiMessageQueue that is blocked. That way a worker thread can run uninterrupted. If you're not worried about your worker thread pausing from time to time to update the GUI, then using Synchronize is prefferable. -- cobines -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
