[Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

[Marcos Douglas]

On Tue, Mar 18, 2014 at 10:04 PM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:
> Marcos Douglas schrieb:
>
>
>> The requisites isn't a secret: a form needs to notify many windows
>> using asynchronous messages. PostMessage do that but some programmers
>> say this is an old Windowish approach so, I'm searching another method
>> to do the same PostMessage does and making the code more cross.
>
>
> A solution depends on the handling of your "asynchronous" messages. As long
> as the windows (forms?) exist in the same thread, all processing within this
> thread must be sequential (serialized). This can be achieved with a single
> queue.
>
> When you want true asynchronous processing, implement an thread with its own
> queue that receives the asynchronous messages. Then you are free to
> implement your own message dispatcher in that thread.
>
> You also can implement your own message dispatcher in the main thread, by
> implementing your own message loop. But then you risk to make the
> application temporarily unresponsive, when your asynchronous events are
> processed before UI messages.
>
> Another solution may be an Idle message queue, and IMO something like that
> is implemented for QueueAsyncCall and OnIdle events. Then it depends on the
> message priority whether it is processed before (high priority) or after
> (idle state) UI messages, in the (existing/your) main thread dispatcher. Or
> you add an OnIdle handler to all target windows, or to the main window only,
> that looks for and processes the asynchronous events in a dedicated message
> queue, without blocking the UI.

The app do not need these sophistications (for now), it needs to be
strong at the first place and I do not want to have problems with
synchronization between threads at this moment. However I like your
ideas... to the future.

> For Windows applications you should eventually know some bits about the main
> thread message queue. Windows e.g. creates mouse move events when needed,
> but not for every single move; instead the message receives the *current*
> mouse position, when fetched from the queue. Similarly a WM_PAINT request is
> queued only when the message queue is empty, and while the update region is
> not empty. This assures that painting has the lowest priority amongst all
> messages in the main message queue. Some other messages are sent immediately
> to a window, bypassing the message queue. And last not least some Windows
> controls bypass (or peek?) the message queue as well, so that some standard
> events are never received by user supplied message handlers. At least I
> found such behaviour with messages related to painting an edit control.

Thanks for the tips.

Regards,
Marcos Douglas