On Mon, Mar 17, 2014 at 12:20 PM, Michael Schnell <[email protected]> wrote: > On 03/17/2014 04:09 PM, Michael Schnell wrote: >> >> >> >> If you meant the self pointer of AMethod, I of course am with you (as same >> is a "procedure of object"). >> > But that is rather trivial, and AMethod could be a procedure of any class > (inducing but not forcing the "TThread" instance that schedules the call. > > >> I think that I need is too much for a simple call to QueueAsyncCall. >> I'm doing tests with FP Observer implementation too. > > A nice trick is to create an instance of a "data holding" object, fill it > and provide it as "Data" with QueueAsyncCall. In the call you can free the > "data holding" object.
I do that today using PostMessage. IMHO the problem in QueueAsyncCall, comparing with PostMessage, it is needs to know what procedure (method of an instance) to call to use on queue meanwhile PostMessage function just put a message on queue. The object that is listening for messages knows what procedure/method to execute itself. > Another trick that also works with TThread.Queue is to provide the data > holding" class with a procedure, create and fill same and provide the > procedure (including instance) with TThread.Queue. Here you need to take > more care with freeing the object. I'm not sure if you simply can do "free;" > as the last instruction before returning from the procedure. I do not have problems using Threads but I don't use TThread.Queue. I just use TThread.Synchronize and this is works for me. I know TThread.Queue is new, but I never used... maybe you can explain me what advantages, please. Regards, Marcos Douglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
