Why would a message box be not displaying?

Question

I am on a MFC project that has a very strange windowing mode setup. I think this setup is screwing up how a owned message box is being displayed.

What is happening is that the message box will not be visible until the ALT key is pressed.

I'm still trying to wrap my head around the window setup they are using, but perhaps someone would be able to give me a clue as to what to look for?

I wrote a workaround where I pass the owner window and the title of the message box to a class which spawns a thread that goes through all the windows and finds a message box dialogue that is owned by the specified owner with the title specified. However, I would have to do a search and replace of over 1000 instances to get this to work system wide.

A better option would be to find the root cause. But the complexity of this is quite daunting. Any clues to what I should be looking for which could cause this behaviour would be greatly appreciated.

Answer 1

This is caused by the MFC CDialog DoModal can't show window if parent window message queue is 'busy' 'feature' where if the message queue contains any messages, it will not show the system message box. (Please vote or comment on that bug. The behaviour is very unexpected.)

I tracked this down by trying to slurp up all of the messages in the queue using this:

MSG msg = { 0 };
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
    TRACE(_T(R"--(,"% *.*s",PEEK,0x%08x,"%s",0x%08x,0x%08x,0x%08x)--" "\n"),
              0, 0, _T(""), msg.hwnd, "Window HAS msg",
              msg.message, msg.wParam, msg.lParam);
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

This would output all the messages in the queue, and showed me what window and what message (in this case, WM_PAINT) was the offender.

I then tracked down what class object that window that was attached to and looked at it's OnPaint() handler.

Turns out, a previous programmer put an if x then return condition before constructing a CPaintDC object. Its constructor calls BeginPaint(), which in turn validates the invalid region. Without validating the invalid region, the system continues to generate WM_PAINT messages, until the invalid region is empty. This will result in the message queue never being empty.

Not sure if this matters, but the relationship between the offending window and the dialogue box was that they were in the same thread, off of the root application window. There were two display modes which had the following setup:

-ROOT                            -ROOT
 +-CHILD                          +-MESSAGE BOX 
  +-MESSAGE BOX                   +-CHILD 
  +-CHILD                          +-CHILD 
   +-CHILD                          +-CHILD < Offender 
    +-CHILD < Offender               +-CHILD 
     +-CHILD