On 05/02/2011 08:14 PM, Bernd wrote:
PostMessage() works (that is what I currently use) and
QueueAsyncCall() did not work when I opened this thread, I will test
it again tomorrow.
Thanks. It dopes work for me now, but I am interested is seeing if it
does work everywhere.
But what I would need for my application is something like
Synchronize(),
Synchronize does work for me (and did work since many months).
After playing with this stuff for a long time, my opinion is that
TThread.Synchronize(), PostMessage() (and TThread.Queue() if once
someone more knowledgeable might care to implement it) should (at least
for non-Windows Widget Types) be done on top of
TApplication.QueueAsyncCall, so that all will work if one does.
I believe you could easily implement TThread.Synchronize in a portable
way e.g. by using a TEvent: The thread queues an asynccall and then
waits for the event. The asynccall calls the method to be synchronized
and the sets the event.
I need to block my camera thread after every frame
until the GUI has updated itself with the newly received frame.
That might result in may completely unhandled frames, as the GUI thread
might not be able to perform the synchronized methods for a huge amount
of time.
So IMHO the better design is to store the data somewhere, set a "buffer
not empty" bit and do an AsyncCall. The GUI event resets the bit when it
has handled the data in the buffer. When the next frame is received by
the thread same checks if the bit is reset (buffer empty)m it acts
accordingly, filling the buffer or throwing away the frame.
Double buffering or a buffer FIFO can be implemented in a similar manner
(e.g. using a TList of buffer pointers).
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
