[Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell
mschnell at lumino.de
Tue Mar 18 12:02:48 CET 2014
On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote:
>
> The LCL is based on the message queue, regardless of any OS or
> widgetset. PostMessage is part of the message queue.
Yep. (Even though I prefer the term "Event Queue" as the queued
information this is not necessarily similar to Windowish "Messages".)
In fact there is an Event Queue in the RTL (that is used e.g. for
TThread.xxx based events) and an additional Event Queue that handles
events based on the GUI the LCL binds to (here the Events are "Messages"
if the GUI is Windows). With Windows, the Queue itself is implemented in
the OS and only _used_ in the LCL, while with any Linux GUIs, the queue
is implemented in the LCL and is fed by Events _generated_ by the GUI
(no idea about Mac). Now, the GUI-attaching "Widget Type"
implementations in the LCL merge the events of both queues, while the
not GUI-attaching Widget types currently even ignore the RTL based queue.
>
> You didn't answer my question: which other event handling model would
> you prefer, for use on any target and widgetset?
Because I don't understand the your meaning here.
- I personally would prefer TThread.Synchronize and TThread.Queue
because both are usable in Delphi, too, and provide as well blocking
(.Synchronize) and non-blocking (.Queue) mode with identical syntax.
- QueueAsyncCall has it's point, as it's easy to transfer a (queued)
parameter to the procedure. With TThread.Queue, this is more effort, as
you need to make the synchronized procedure part of a class you install
an instance of before sending it to the main thread via TThread.Queue,
and later, the instance of course needs to be freed (this seems to be
possible in the synchronized procedure itself just before returning)
- I don't understand what you intend by mentioning the "mouse input and
painting" issue.
-Michael
More information about the Lazarus
mailing list