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



--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to