[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