On Tue, Mar 18, 2014 at 10:04 PM, Hans-Peter Diettrich <[email protected]> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
