Find out why application thread messages disappear without using TSaveDialog

Question

Development using RAD Studio (Delphi) v10.2.1 (Tokyo release 1) on Windows 10 "Update for Developers" 64-bit, but 32-bit development.

A VCL application with multiple background threads, each of which uses Indy TidHTTP to retrieve network resources. Synchronization between the main thread and background threads is done using message queues (calls to PostThreadMessage). This is quite complicated, because offering direct code here would be difficult and erratic, so I start with a verbal description.

What should happen: open a file with links to external resources, this generates HTTP requests and transfers them to the background, and then expects incoming messages in the application message queue to say that the resources have been downloaded. Application messages are matched in the event code assigned by TApplication.OnMessage (which, I suspect, is the cause of my problem).

He works. Everything goes smoothly in most cases. But if I open TSaveDialog - even if I canceled the dialog and didn’t do anything, then the messages disappear from the application message queue.

In the process of writing log messages (it is impossible to debug directly, because it upsets the time required for the problem to occur). I found out that the background threads do post messages (and get a positive response from PostThreadMessage), but they never appear in my TApplication.OnMessage event code.

I saw that some sneaky code in different libraries will create their own PeekMessage / TranslateMessage / DispatchMessage loops, but not all of them do not forget to check if there is a TApplication.OnMessage event. But I just looked at the VCL code and dozens of third-party libraries that I use, and did not find any examples of this that could suffer in this case (as far as I can tell).

Note. I use madExcept, Indy, FastReport, AddictSpell, SynEdit, VclStyleUtils (among several less well-known libraries).

Note 2: I am wondering if this could be related to updating Delphi 10.2.1 or Windows 10 Creator, since I also see some other strange behavior (long delays with the first exception or the first TOpenDialog - but only on some applications) which definitely did not happen with 10.1 (I did not use 10.2.0) .... But it could be (maybe something else).

So my question is: what can I do about this?

Any suggestions on how to find / check if there is any other code stealing application messages? Anything else I should look for other than PeekMessage?

Is there any other way to intercept application message queue messages that can allow me to avoid the problem?

If the best options are not displayed, I may have to abandon the use of application thread messages and implement my own messaging / synchronization system, which I would prefer not to do after all this works fine the rest of the time.

Answer 1

You mentioned PostThreadMessage . Do not look further. You cannot use this if you do not manage all message cycles that could disable streaming messages, but you do not. Message outline with modal file is not available. It will disable thread messages intended for another message loop and not know what to do with them.

The solution is simple enough. Send messages to a window, not to a stream. Thus, all sane message loops (message loop of the modal file dialog box) will send messages to the intended recipient window.

In Delphi terms, this involves using AllocateHWnd or similar to create a hidden window for receiving messages.

Raymond Chen raised this topic here: Why do messages sent by PostThreadMessage disappear?