Form.ShowDialog() or Form.ShowDialog(this)?

Viewed 60961

I heard that if I call form.ShowDialog() without specifying the owner, then there can be a case when I will not see the dialog form on screen (it will be hidden with other windows). Is it true? I used ShowDialog() without specifying the owner hundreds of times and I never had any problems with that.

Can you please explain in which situation I could get the described problem?

UPDATE:

Well, I did many experiments and I couldn't get any real unexpected problems with using ShowDialog() (without specifying the owner).

So I think it's just rumors that ShowDialog() can lead to problems. If you don't agree - give me a code sample please that leads to a problem.

9 Answers

One annoyance I found with ShowDialog() vs ShowDialog(this).

Run the TestApp, show the newform.ShowDialog(), click "show Desktop" on your taskbar or Quick launch toolbar, click on the TestApp on the taskbar. It shows the Mainform. You have to do an Alt-Tab to get to your newform.

VS

Run the TestApp, show the newform.ShowDialog(this), click "show Desktop" on your taskbar or Quick launch toolbar, click on the TestApp on the taskbar. It shows the newform on top.

"Currently active Window" usually refers to the foreground window, but only if it belongs to the current thread - see GetActiveWindow in MSDN.

(The actual information is in the community content, but the commenter is right that there is no "per-thread active window", AFAIK).

So when the user switched to another applications (or threads) window, you end up with some "default window". Even if .NET does some magic here, the modality will be broken: the intended parent window does not get disabled (e.g. you could switch to your main window, and close it, or modify something, which often breaks your application due to reentrancy).

Also, if another application is currently active, your dialog will not be shown on top, but it will be hidden behind some other window.

As a minor annoyance, the initial position is usually incorrect or misleading.

In practive, this happens rarely, though: if you open the dialog in response to a menu or button click on your main window, the user doesn't will virtually never manage to switch to another window.

However, it is technically possible, and quite likely to happen if you open the dialog in response to some automation, external message etc.

The parameterless ShowDialog() simply uses a "default" parent. For what it's worth, the default parent is whatever the "currently active window" is. When you care what the parent is, you need to set it explicitly.

My problem was to call ShowDialog() from a form that was brought up with ShowDialog(). The result was a hidden form with no way to access it to close it.

After reading this topic, I tried ShowDialog(this) and it worked perfectly. The second dialog showed on top, centered, and completely functional. When the second form was set to Dialogresult.OK it allowed access to the underlying dialog which was able read its properties and then close it.

Related