On 03/18/2014 05:52 PM, Joao Morais wrote:
I missed the "async" part, sorry. What about reuse App.QueueAsyncCall
with interface?
Combining the Interface idea with asynchronous signaling in fact is a
nice idea.
The real issue is that in many cases you need to queue not only the call
but the parameters for the call as well.
Here we have:
- TThread.Queue only calls the call (but of course this is the
procedure address and the "self" of the instance you use in the argument
when calling TThread.Queue
- Application.QeueAsyncCall additionally takes a pointer as a
parameter that is queued and when scheduled given to the signaled
procedure called in the main thread
But obviously it can be necessary to queue more information than just a
pointer.
I did a testing program using TThread.Queue.
I defined a "TData" class that contains the data and a procedure with no
parameter.
When placing the event, in the worker Thread do:
- create an instance of the TData" class, just storing the reference
in a local variable " Data: TData; "Data := TData.Create; " ("Data"
funnily is long forgotten when the call in fact is scheduled in the main
thread)
- Fill "Data" with the data to be worked on in the main thread
- do " Queue(Data.QueuedCall); "
Now some time later the call is scheduled in the main thread and
QueuedCall starts running.
- You can correctly access all data in this instance of the TData
class. Any other work in the WorkerThread would have created a new
independent instance of same
- After doing what needs to be done you just do " free; " as the
last line of the QueuedCall procedure. Here the current instance it
works on is freed. This does not (seem to) be a problem, as after the
free you return to completely unrelated stuff.
I am not experienced with Interfaces, but I do know that interfaces can
create and free class instances automatically "under the hood", and
hence it might be better programming style to use same instead o
manually do a " Create " and " Free; " in user code.
If it would be possible to do such an interface driven thingy in a
library in a way that the actual structure of the data can be defined in
user code, this would be a great addition (IMHO better for the RTL than
for the LCL).
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
