Thread: Not so modal CDialogs

We had some weird crashes in our client application and I finally reproduced it in a wizard generated 3-liner:

This "works" in VC6 and VC7.

Create a Dialog based MFC Application. Deselect all features. When your Dialog comes up, double click the OK Button. This will send you directly into the code. You just overwrote OnOK. Now make it look like this, opening up another copy of the same dialog:

Code:

void CCDialogTestDlg::OnOK() 
{
	CCDialogTestDlg dlg;

	dlg.DoModal();
}

While obviously stupid, it will show what my problem is. Start the program. Click OK. Move the dialog a bit. Click OK on the new Dialog again. You now have three windows, each one modally bound to it's parent. Click with the mouse on each one, only the topmost window ( the last in the modally opened chain ) will activate.

So far, it's working as intended.

Now select the middle/second window in the chain in the taskbar. Voila, the second window is selected and ready for input by keyboard ( not usable with the mouse though ).

You can probably imagine that working with and closing the second window in a three ( or more, test it ) dialog chain will crash any application. I cannot have a user select which dialog he wants to answer to, that's what modal dialogs are for: topmost first. Nothing else.

I tested this in VC6, then hoped it was a bug and tested it in VC7 resulting in the exact same behaviour. So I guess it must be me being totally confused and unable to set the right flag when creating a dialog. Does anyone have any ideas how to solve this ?

that is wierd, never noticed that before....

I can only get the middle dlgs to respond to the ENTER key not the TAB key in MSVC 2003. This does allow me to click the dlg's default button and so recreate the issue.

Try removing the 'Application Window' style.
This is the flag that gives a dlg an icon in the taskbar.

I removed the WS_EX_APPWINDOW style, so I have only one taskbar entry for the applicaion and it works fine. But I can already hear our users screaming. It's clearly unusable ( read: different than yesterday ) now and no one can work anymore

I don't want to close the underlying dialogs but return to them when the one on top closes. Example at hand: First dialog is a tree of jobs. Click on one and another dialog opens with all modules of said job. Click on a module and you get another dialog for specific module data. Close it, get back to the job details. Close that and you get back to the job tree.

Originally Posted by nvoigt

..it works fine. But I can already hear our users screaming. It's clearly unusable ( read: different than yesterday ) now and no one can work anymore

Bloody users!

If their not complaining about the software, they're finding new and inventive ways to break it.....

Doesn't the dialog class have a constructor argument where you pass the parent window? Pass the current this pointer to that.
If it doesn't have such an argument (as it's your class, after all), give it one. You need it. Read up on the Modality series in the Old New Thing blog, starting on this archive page, and look in particular at part 4.