Modal dialog and messages

'lo everybody.

I'm working on this very complex software, and there is this small bug I don't know how to get rid of. Perhaps some of you might be able to help.

Here is what happens : a "splash" window is created at startup while the software performs various initializations. This window is a modal dialog, called with DoModal(). When the initialization is complete, another thread posts a custom WM_USER message to the splash window, which then closes itself with EndDialog(IDOK) and returns from the DoModal() call.

This works fine, except if the splash window is being moved when the message is sent. Under these circumstances, it seems the message is either ignored or lost.

So, is this "normal" behavior? I'm guessing the WM_MOVEWINDOW or whatever message takes priority over the custom WM_USER message. More importantly, how can I correct this? (I'm thinking of making the splash window not moveable, but this obviously is a workaround, not an actual fix.)

Thanks for your help!

Did you try a SendMessage instead of a PostMessage? This API should wait untill the message was processed ...
You should read the documentation of SendMessage and SendMessageTimeout...


regards
HoM

Quote:

---

Originally Posted by wlof

So, is this "normal" behavior? I'm guessing the WM_MOVEWINDOW or whatever message takes priority over the custom WM_USER message. More importantly, how can I correct this? (I'm thinking of making the splash window not moveable, but this obviously is a workaround, not an actual fix.)

Thanks for your help!

---

1. There is no WM_MOVEWINDOW at all.
2. I never heard something about any "priority" over user defined messages. However, messages that have been posted are placed in the message queue and not processed until window procedure ends processing some other ("sent") messages.
3. You should NOT use WM_USER range for your custom user messages since this range is already used by Windows and MFC.
You should use WM_APP range instead.

Thanks to you both.

HoM: Thanks, but the problem isn't whether the call is blocking or not. The PostMessage() is actually the last step of an initialization thread, which terminates itself right after that, so it doesn't really matter whether Post or SendMessage() is used.

VictorN:
1. Yep, I made it up. I don't know if there is an actual "high level" message to tell a window it is being moved, or if it's just the "low level" WM_MOVEMOUSE|WM_LBUTTONDOWN messages or something else entirely.
2. Is there any way to manipulate or bypass the message queue? If I want the window to close itself, I think I can safely tell it to drop all other unprocessed messages.
3. Thanks for the tip. I switched the messages to the WM_APP range, but it doesn't seem to change anything.

Quote:

---

HoM: Thanks, but the problem isn't whether the call is blocking or not. The PostMessage() is actually the last step of an initialization thread, which terminates itself right after that, so it doesn't really matter whether Post or SendMessage() is used.

---

Did you give it a try?

regards
HoM

Quote:

---

Originally Posted by HoM

Did you give it a try?

---

Yep. From what I can tell, it changes nothing.

Seems the issue is not unknown ...
MS Support

... kind of. Hard to understand this article :-(


regards
HoM

Well, I managed to solve my bug in a simpler way. The exact problem was that the main window can receive messages from other threads that triggers graphical changes, but the graphical elements might not exist yet because the main window's OnInitDialog() method is still stopped in dlgSplash.DoModal().

It now checks whether an element exists before attempting to update it.

I'm still interested in whether it's possible to manipulate the message queues or not, but that's just curiousity at this point. :)

I think the simplest solution is to just call DestroyWindow. It cannot fail, no matter what UI you have or don't have. Just make sure, before calling it, that the window exists. And also make sure that no other code sequence will attempt to access it anymore.

There is no WM_MOVEWINDOW message but there is WM_MOVE and WM_MOVING.

In my opinion there are two categories of programmers who touch the message queue:

1. Highly skilled programmers writing advanced applications to deal specifically with the message queue.

2. Those who don't know enough programming to achieve their goals using normal programming techniques.

(I excluded the cases when it's clearly stated in the MSDN that the message queue must be modified.)