I have an MFC application that spawns a number of different worker threads and is compiled with VS2003.
When calling CTreeCtrl::GetItemState() I'm occasionally getting a debug assertion dialog popup. I'm assuming that this is because I've passed in a handle to an invalid item but this isn't my immediate concern.
My concern is: From my logs, it looks as though the MFC thread continues to service a number of windows messages whilst the assert dialog is being displayed. I thought the assert dialog was modal so I was wondering if this was even possible?
The message box that shows the assertion failure has a message pump for its own purposes. But it'll dispatch all messages that come in, not just those for the message box (otherwise things could get blocked).
With a normal modal dialog, this isn't a problem because the parent window is typically disabled for the duration of the dialog.
The code that launches the assertion dialog must've failed to figure out the parent window, and thus it wasn't disabled. This can happen if your main window isn't the active window at the time of the assertion. Other things can go wrong as well.
You can change how Visual Studio's C run-time library reports assertion failures with _CrtSetReportMode. You can make it stop in the debugger and/or log to the output window instead of trying to show the dialog.
Dialogs (even a messagebox) need to pump the message queue, even if they're modal. Otherwise how would they know you clicked on the "OK" button?
If you need to stop everything when an assert triggers it's usually not too difficult to write your own implementation of assert() (or ASSERT() or whatever) that will break into the debugger instead of displaying a messagebox that asks if you want to break into the debugger (maybe only if it determines that the debugger is attached).
Related
I have a multi-threaded application with several supporting DLLs and several popup dialogs. My Main App loads all DLLs on startup, which creates all popups, but they are kept hidden until needed.
When the user presses a button in the main app, a particular popup is shown (from the DLL) by calling ShowWindow( SW_SHOW ) (modeless)
Sometimes (1-in-10 times?) the popup simply fails to show and the Main App hangs. OnShowWindow of the Popup dialog is never called. I have tried calling ShowWindowASync instead, and it still fails to show the popup sometimes, but this call doesn't lock the Main App.
This problem only affects popups within a single DLL.
If the popup shows the first time ShowWindow is called, it can be closed and re-opened indefinitely throughout the lifetime of the Main App. If (using ShowWindowASync), the popup fails to show, it will never show during the lifetime of the Main App. I can re-run the application (without rebuilding anything) and there is a hit-or-miss chance that it will work or fail. I haven't been able to identify any predictive conditions or properties.
I have used tools to renumber all of my resource elements so that there are no conflicts throughout the solution.
UPDATE:
I used Winspector to get some information about the dialog when it does and does not work.
When the dialog works (shows properly), Winspector reports that my dialog has valid position (10,96, 1015, 514), style attributes that match the resource template, ID of 0 (not sure what ID means), and the "Owner EXE" is "MyApp.exe" - I can see many messages passing in and out of the dialog, including WM_SHOWWINDOW.
When the dialog fails (does not get a show window message), Winspector reports position (-1512, 190, -517, 634), style attributes that do not match the resource template, ID 509290824, and owner EXE is "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" - I also do not see ANY messages in the message viewer within Winspector when the dialog fails to show.
Clearly, the dialog is not getting created correctly. CDialog::Create never fails for me. Additionally, I experience this problem in release (not using Visual Studio) so it's not a VS-specific problem.
The dialog was getting created from a thread that was not executing a message pump. This was the root problem. I had tried to initialize all dialogs (i.e. call "Create") from an "init" thread, and then use them later on in the winproc/GUI thread. Can't do this apparently.
A pointer to the dialog was then retrieved into the winproc/GUI (which has a message pump), but by that time, the dialog was already "corrupt" and no longer responding to winproc properly
I have the main window, and then the user can "pop up" one of the frames in the application so that it floats rather than being contained in the main window. There are multiple frames that can be popped up so that in a given time there might be three WS_POPUP windows.
The problem is when I want to show the modal dialog, I can only disable one of them using the parameter in the DoModal function. How can I disable all top-level windows using DoModal? I can't simply disable the windows before showing modal and then enable it back because There could multiple chained modal dialog (one modal dialog opens up another modal dialog).
Does the API provide a way to do something like this? I've googled this for two hours and can't find a good enough solution. I'm using a combination of MFC, WTL, and ATL.
Thanks in advance!
As I understand the problem, it is the same like the MFC frame windows work.
In fact only the CFrameWnd of an MFC application gets disabled. On arrival off the WM_ENABLE message (with FALSE) BeginModalState is called and this function just disables it floating "child windows" of the CFrameWnd.
Same again, when EnableWindow (WM_ENABLE arrives with TRUE) is called for CFrameWnd. EndModalState is called and all disabled "child and floating" windows are enabled again.
See the MFC implementation of CFrameWnd::OnEnable, BeginModalState, EndModalSTate in the source code.
So you main window knows it's own popups. Upon launching the true modal dialog, and disabling this parent, it will disable it's floating popups.
The trick is that CDialog::DoModal needs the real parent... if not given in the constructor it guesses the correct one in most cases. For your case it should be necessary that you provide your "main window" as the parent window... same for message boxes...
I have a modeless dialog that is sometimes left up on the screen when I go to close my main app. If I close it manually, all destructors get called properly. But so far, if I try to do it through C++ code, I encounter problems in the Debug build that don't give me confidence in what is happening in the Release build.
What is the correct way to close a modelss dialog? Documentation for PostQuitMessage() indicates it closes entire threads (is a modeless dialog run in a separate thread, or just part of the single MFC App UI thread?). Calling DestroyWindow() gives me issues in practice. Sending a WM_CLOSE doesn't feel like the right thing to do. And CWnd::EndDialog() only applies to Modal dialogs. Does the correct answer lie among these... or somewhere else?
I have a strange error and spend hours in the debugger without finding a solution.
(But it helped me to fixed another error that you should never call EndDialog from a WM_KICKIDLE task).
My problem is that i have a main window and a modeless dialog window wich raises a modal subdialog window. When the subdialog window is closed. The modeless dialog window turns itself into a modal window. My code really does leave the modal loop. And if i close the now modal window it behaves like an invisble modal window is active, meaning no interaction is possible anymore.
When i only run a modal dialog on top of the main window it is closed fine.
BTW: The main window is not the one available view CWinApp::m_pMainWnd but a new create FrameWindow. I hide the p_MainWnd and use it as an invisible message only window. From some comments and my debugging session i found that the pMainWnd has some special meaning but i could figure what exactly it has to do with modal windows (there is an undocumented "CWinApp::DoEnableModeless" for example).
EDIT: I'm posting a WM_CLOSE to the dialog and then use EndDialog(0) from the OnClose() handler to exit the modal state. I also tried to use EndDialog(0) directly. There is no difference between this two methods.
When MFC creates a modal dialog, it makes it modal by disabling the windows above it. The code that reenables those windows occurs when the dialog ends normally with a call to EndDialog. If anything prevents that code from running, the other windows will be locked out.
Modeless dialogs are a different beast, and there's a note specifically in the EndDialog documentation warning you to use DestroyWindow instead.
Maybe this is justifiable but I have a question:
why are you using hidden window? Was it created as message only window (passing HWND_MESSAGE as a parent handle and Message as a class) or you just call it message only?
OK, a little more info about MFC and dialogs.
MFC does not use Windows modal dialog. It always creates modeless dialog; either Create or DoModal call in turn ::CreateDlgIndirect windows API.
Modeless dialof rely on the main window message dispatch, while modal calls RunModalLoop that is similar to MFC window message pupmp (not a message loop).
It runs in the main thread of execussion without freezing because it allows for idle processing (calls OnIdle).
How do you dismiss the modeless dialog? As Mark pointed you should use DestroyWindow.
As for m_pMainWnd, MFC framework uses it extensively to determine may things that control main window behavior. By changing it you may have created the behavior you experience.
Did you set the value to a newly created frame you treat as a main window?
What kind of MFC application is it? SDI or MDI?
Would it be possible to create test app to duplicate this behavior and post it somewhere for download?
By the way, you do not have to be concern about DoEnableModeless, since it does not do anything but calls hook (COleFrameHook type) that is spasly used, unless you are trying to implement some functionality using OLE or ActiveX or you are trying to marry MFC and .NET Windows Forms.
In conclusion if your (or third party code uses this hook, I would suggest checking the code in the COleFrameHook class.
Good day!
I have an MFC dialog with progress.
Dialog automatically closes after reaching 100% using PostMessageW(WM_CLOSE).
The problem is, when, during progress, I'm moving dialog over the screen, dialog is not closing and WM_CLOSE message is ignored. Any suggestions? Thanks.
For a modal dialog you shouldn't really need to use a WM_CLOSE message.
Normally you'd use the OK or Cancel button events to close it, call the EndDialog method from functional code or just return when your processing is complete (assuming that its the process run as soon as the dialog is initialised). You can set your return value at the same time e.g. EndDialog(2);.
Either way the dialog will close once th current message handler returns, so there could well be a delay, in closure but it shouldn't be much.
Is the activity behind progress bar done in a separate thread? It look like to be the case otherwise when you drag the dialog the progress bar would have froze until you release the dialog than it would have resumed. This means you might have to look into inter thread communication, how the message is being posted to the dialog HWND.
It might have to do with the dialog being in freeze (no activity) state while you are dragging it which seems to be normal windows behavior. If that is the case you could use signals/CEvent to tell the dialog to close down.