[Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

[Hans-Peter Diettrich]

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.


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.

DoDi