1

The Questions:

Has anyone seen invoking of one modal dialog from another modal dialog cause the modality to get undone?

If you wanted to make a call with ShowDialog so that you get back a result, but without it being modal (other Forms still respond), how would you do it? (We're not trying to do that... but if there is a way to do that, maybe we're doing that accidentally.)

The Details:

We have implemented our own Print dialog that has buttons that bring up the standard PrintDialog, the standard PageSetupDialog, and the standard PrintPreviewDialog. And the printing is all done with our own PrintDocument class derived from the standard PrintDocument class. So, we're trying to follow the standard practices... we just have a few extra settings that we need the user to start with.

We invoke our Print dialog from a menu using ourPrintDialog.ShowDialog(mainWindow). When it comes up, it is properly modal (all other windows are non-responsive... in particular, that mainWindow). From that Print dialog, there are buttons to invoke each of the other three dialogs... and all are invoked with ShowDialog(ourPrintDialog), making that first Print dialog as its parent. In the case of the PrintDialog and the PageSetupDialog, they come up modal (mainWindow and ourPrintDialog and all other windows are non-responsive). And when we OK or Cancel those, it returns to the first Print dialog (ourPrintDialog) which is still modal (no other windows respond).

However, in the case of the standard PrintPreviewDialog, although we invoke it the same way (ShowDialog with the first dialog as its parent), it comes up not entirely modal. Our main window becomes responsive again. So, you can start manipulating the underlying document that the Print dialog is in the process of printing... which of course violates many assumptions. And when you close the Preview dialog, returning to the original Print dialog, it is also now not in a modal state... the main window is still responding.

We have tried doing this in a plain test app, and it works fine... the modality is not broken when going into the PrintPreviewDialog. So, it seems to be some specific interaction between the PrintPreviewDialog (since it doesn't happen with the other two) and our app's main window (since it doesn't happen with the test app). Any suggestions on what that might be? (And hence my two questions above.)

Thanks in advance for any suggestions!

Brian Kennedy
  • 3,499
  • 3
  • 21
  • 27
  • Does it take more than 5 seconds for the print preview to be generated? Then this is normal. The original windows get replaced by a "ghost window", it shows "Not Responding" in the title bar. Those windows are not modal and don't otherwise respond to clicks. – Hans Passant Dec 17 '12 at 20:40
  • There may be some cases when it takes more than 5 seconds... but I have never seen a "Not Responding" window... and my issue is NOT that there's windows that "don't otherwise respond to clicks"... rather, my issue is that the other windows DO respond to clicks when they shouldn't be because I am in the middle of a ShowDialog so nothing but that dialog should be responding. – Brian Kennedy Dec 17 '12 at 20:45

1 Answers1

0

Not sure why it's happening , but you might try running Spy++ on the windows and watch the messages that flow, might give you a clue as to what is happening between the windows, or the properties of the windows in question.

Dan OConnell
  • 217
  • 1
  • 8