[Lazarus] Application.QueueAsyncCall()

[Brad Campbell]

cobines wrote:
> 2010/1/20 Brad Campbell <brad at wasp.net.au>:
>> Is QueueAsyncCall() threadsafe?
> 
> As far as I know it is not.
> 
>> Let's say I have a communications child thread and I want to trigger a call
>> back in the main GUI thread. Traditionally I'd do something ugly like have a
>> timer polling a variable used as a flag, or polling a RtlEvent on a short
>> timeout, but this seems like a much nicer solution.
>>
> 
> You can call TThread.Synchronize(), your thread will be stopped until
> the GUI thread executes your function.

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.

> Other solution is to create a separate thread for handling such GUI
> functions (take a look at attached source); this doesn't stop your
> child thread. Be careful however because in this case you don't
> control when your method is called (it may be after your thread is
> already finished).

That's a really interesting solution. I *thought* the issue was that the update of GUI elements must 
only be done in the main thread. I actually don't have a problem running the callbacks from the 
comms thread as the callbacks are executed between packets in a polled system, so it's not at all 
timing critical. I was more concerned with updating the GUI components in a threadsafe manner.

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?

Really appreciate the reply, it has been incredibly helpful.

Regards,
Brad
-- 
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.