Originally shared by Thomas Mueller (dummzeuch)
Originally shared by Thomas Mueller (dummzeuch)
Using Application.ProcessMessages is being frowned upon by many because often it means that your program design is flawed. These people usually suggest you should use multi-threading instead, which then opens another can of worms. First of all, let me…
http://blog.dummzeuch.de/2018/09/29/calling-application-processmessages-in-a-delphi-program/
Using Application.ProcessMessages is being frowned upon by many because often it means that your program design is flawed. These people usually suggest you should use multi-threading instead, which then opens another can of worms. First of all, let me…
http://blog.dummzeuch.de/2018/09/29/calling-application-processmessages-in-a-delphi-program/
You also need to worry about reentrancy. I.e. processing a new message before the processing of the previous one have completed, something that is particularly troublesome during UI updates.
ReplyDeleteAttila Kovacs, can you post an example? I am interested.
ReplyDeleteAttila Kovacs thank you!
ReplyDeleteI use a Thread and MsgWaitForMultipleObjects (also frowned upon) to deal with this.
ReplyDeleteAn example would be to use an Anonymous Thread to do all work and override the Start method in a Helper to add my own Wait routines.
Thread Start(twkAsync) will use MsgWaitForMultipleObjects with the Thread Handle, SyncEvent, and a Global Shutdown Event.
It wakes on all those and on any messages that require processing, each one is dealt with appropriately.
I use worker threads, and TOmniQueue as postboxes between the threads.
ReplyDeleteAttila Kovacs I apologize but in your example I am not able to find a way on how to handle an Abort button.
ReplyDeleteAttila Kovacs Thank you! Yes I am interested:-)
ReplyDeleteAttila Kovacs thank you so much! Now it works fine and it is conceptually simple and elegant: I like it very much.
ReplyDelete