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 -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
