Weird problem of nested ShowDialog() behavior

M

momonga

Hi, everyone.

I have a weird problem of nested ShowDialog() behavior.
I believe that the ShowDialog mothod shows a Form as a modal dialog,
so you can not perform any action on any other Forms until you close
the modal dialog.
But I found the way to violate this rule.

Let's say there are 3 forms; TopForm, SecondForm and ThirdForm.
Like this...

static class Program
{
[STAThread]
static void Main()
{
Application.Run(new TopForm());
}
}

public class TopForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
SecondForm form = new SecondForm();
form.ShowDialog(this);
}
}

public class SecondForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
ThirdForm form = new ThirdForm();
form.ShowDialog(this);
}
}

Do the following steps.
1.Click the button on TopForm to create the SecondForm
2.Click the button on the SecondForm to create the ThirdForm.
3.You can now see the 3 Forms are shown.
4.Click the button on the taskbar for the SecondForm, you can see the
SecondForm is focused.
5.Simply push the button on the SecondForm by pushing the enter key.
6.Now you have two ThirdForms.

Assume that the ThirdForm is exit-confirming dialog, and popuped
multiply.
This is problem, and I don't like this behavior.
I'd like them to work when i click the button on the task bar for the
SecondForm simply to bring the ThirdForm to top-most or so...
Any suggestions are really grateful.

Thanks!!!!
 
R

Registered User

Hi, everyone.

I have a weird problem of nested ShowDialog() behavior.
I believe that the ShowDialog mothod shows a Form as a modal dialog,
so you can not perform any action on any other Forms until you close
the modal dialog.
But I found the way to violate this rule.

Let's say there are 3 forms; TopForm, SecondForm and ThirdForm.
Like this...

static class Program
{
[STAThread]
static void Main()
{
Application.Run(new TopForm());
}
}

public class TopForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
SecondForm form = new SecondForm(); form.ShowInTaskbar = false;
form.ShowDialog(this);
}
}

public class SecondForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
ThirdForm form = new ThirdForm(); form.ShowInTaskbar = false;
form.ShowDialog(this);
}
}

Do the following steps.
1.Click the button on TopForm to create the SecondForm
2.Click the button on the SecondForm to create the ThirdForm.
3.You can now see the 3 Forms are shown.
4.Click the button on the taskbar for the SecondForm, you can see the
SecondForm is focused.
5.Simply push the button on the SecondForm by pushing the enter key.
6.Now you have two ThirdForms.

Assume that the ThirdForm is exit-confirming dialog, and popuped
multiply.
This is problem, and I don't like this behavior.
I'd like them to work when i click the button on the task bar for the
SecondForm simply to bring the ThirdForm to top-most or so...
Any suggestions are really grateful.

Setting the modal forms' ShowInTaskbar property to false will eliminate the
issue. It's a matter of scope, ShowDialog makes the form modal to the
application but not to the desktop. Showing the buttons in the task bar lets the
desktop's focus be transferred to the individual form and not the application.

regards
A.G.
 
R

Registered User

Except that it doesn't. Most user input is still disabled, even though the
form has been activated. You can't click on the button. You can't even
use the space bar to select it, as you would be able to if the form were
truly active. There's just this odd little loophole that lets a particular
kind of input (the Enter key) get through.

It's true that setting ShowInTaskbar is yet another work-around to the
issue. But that then assumes you don't want the window to be seen in the
taskbar. That's often the case, but not always.

If that is not the case the design should be revisited. Programmatically the
design intentionally denies focus to the form2 when form2 calls
form3.ShowDialog. The UI portion of the design intentionally permits form2 to
receive focus even though the programmatic intention is form3 should retain
focus until dismissed.

There is no reason to consider the issue a bug or that setting the ShowInTaskbar
property is a work-around. The property makes no assumptions beyond a default
value. The property itself allows the developer to _explicitly_ determine the
form's behavior WRT the taskbar.

The documentation for the ShowInTaskbar property

<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar(v=vs.110).aspx>

contains VB, C# and C++ examples of "how to use the ShowInTaskbar property to
make a dialog box that is not displayed in the Windows taskbar." Each sample has
an explicit comment about setting the form's ShowInTaskbar property to false
before invoking the form's ShowDialog method.

The OP's unexpected behavior is a design issue. The design accepts the
ShowInTaskbar property's default value for its modal forms. This opens the path
to the crossed-purpose design behavior where form2 should and shouldn't have
focus at the same time.

regards
A.G.
 
R

Registered User

[...]
It's true that setting ShowInTaskbar is yet another work-around to the
issue. But that then assumes you don't want the window to be seen in the
taskbar. That's often the case, but not always.

If that is not the case the design should be revisited. Programmatically the
design intentionally denies focus to the form2 when form2 calls
form3.ShowDialog. The UI portion of the design intentionally permits form2 to
receive focus even though the programmatic intention is form3 should retain
focus until dismissed.

I disagree with your assessment that "the UI portion of the design
INTENTIONALLY permits form2 to receive focus..."
If the intention isn't to permit form2 to receive focus, the form's
ShowInTaskbar property should be set to false.
If you attempt to reproduce the same behavior with just two windows, one
modal and one not, it works differently: selecting the non-modal window
from the task bar does NOT cause it to become active. If it's intentional
that the window that doesn't receive input can still be made active via the
taskbar, then it's a bug that you can't activate EVERY window via the
taskbar.

One way or the other, there's a bug here. So, which do you think is the
more plausible interpretation? Are you really going to tell me that you
think the bug is that in the two-window scenario, the parent dialog should
be permitted to become active even though it's not now?
I see the problem as an artifact of cascading modal forms and a failure to
properly set the ShowInTaskbar property before invoking ShowDialog.
(I also find your distinction between "programmatically...denies focus" and
"UI portion...permits focus" very strange indeed: the entire thing is "UI",
so to think that there's any sort of non-UI consideration at play, as your
distinction appears to imply, is really odd).

One action is performed programmatically while the other results from user
interaction. That isn't a subtle distinction. When unintended paths exist users
will find them sooner rather than later.
I really don't think it's intentional. It makes no sense that any but the
active, modal dialog could be activated, and indeed this is how the simpler
scenarios work.
Agreed but simpler scenarios don't include nested modal dialogs. IMO a need for
nested modal dialogs suggests a need to review the design. Unexpected behavior
is also a reason to re-evaluate a design/implementation.
Unless you can point to an official Microsoft statement stating both that
the behavior is intentional _and_ providing a logical user-scenario example
of why the design was _intentionally_ decided to be that way (i.e. why it's
useful to be able to cause a window that isn't accepting user input to
become the active window), I see no reason to believe that the behavior is
intentional.
The decision that causes the unexpected behavior was not made in Bellevue. The
unexpected behavior occurs because the implementation accepts the default value
of ShowInTaskbar when showing a form modally. From version 1.1 the documentation
clearly illustrates the use of the ShowInTaskbar property before invoking
ShowDialog.
Even in XP, there were potential reasons to not hide a window's presence in
the taskbar, and with the "live" thumbnail views available in Windows 7,
there's every reason to want to keep the window there, even when the the
window itself shouldn't be accessible.
Why choose to permit the window to be accessible when it shouldn't be? The OP
offered no reason why it is necessary to show the modal windows in the taskbar.
Making the window accessible is the source of the unexpected behavior.

The taskbar APIs can be used if specialized behavior is desired.
For certain programs it may be acceptable to hide the window in the taskbar
while a child dialog is present, but that does not justify the activation
behavior, nor does it in any way suggest that ALL programs should be
expected to do so.
The activation behavior is completely dependent upon the application's
implementation.

If it is desired that form2 receive focus after it has created and displayed
form3, form2 should call form3's Show method rather than ShowDialog. If form2's
ShowInTaskbar property is set to true, the desired behavior will be achieved.

If form2 shouldn't receive focus until form3 is dismissed, its ShowInTaskbar
property should be set to false before form2.ShowDialog is invoked. Once again
the desired behavior will be achieved.

In both scenarios the implementation's failure to correctly set the
ShowInTaskbar property will result in some form of unexpected behavior.
Different forms of unexpected behavior will occur if the incorrect method is
called to display form3. I don't see a Framework bug.

AFA there being a bug in the unexpected behavior I would agree except the
unexpected has no defined behavioral metrics. ;)

regards
A.G.
 
R

Registered User

Says who?
Who says not? Have you ever seen the sentences
"You can use this property to prevent users from selecting your form
through the Windows taskbar."
and
"Do not allow form to be displayed in taskbar."
on the same page of .NET documentation?
The ShowInTaskbar property controls one thing: whether the window is shown
in the taskbar. That is completely different from preventing the window
from being activated.
Are you absolutely certain in your assumptions regarding the ShowInTaskbar
property?
Where does Microsoft state that its function is overloaded to also include
preventing the window from being activated?
Although there is no mention of overloading, the statement you desire can be
found at
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
Like it or not, nested modal dialogs do occur in normal, usable programs.
The mere fact of nested modal dialogs does not in and of itself indicate a
design or implementation error.

Heck, even Visual Studio (with which I hope you are familiar) does it. You
can select "File/Open...", which brings up a modal dialog. Then in that
dialog, you can select a file and then click the drop-down arrow on the
"Open" button to choose options such as "Open With...". Which, incredibly
enough, shows another modal dialog.

Your claim that there's a program design or implementation error just
because there are nested modal dialogs is a complete non-starter.
Don't be putting words into my mouth. Being fully aware that nested dialogs are
not rare, I deliberately chose the phrase "suggests a need to review the
design". Sometimes nested dialogs represent the best implementation and
sometimes not.

In the VS example with File|Open why doesn't the unexpected behavior occur with
the nested dialogs? Could it be each modal form's ShowInTaskbar property is set
to false? What could be the intended use of the ShowInTaskbar property?

From
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
OK again from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
First of all, Microsoft headquarters is in Redmond, WA. The Windows and
.NET dev teams remain there, at least for now.
Many projects cross the border between the two towns. In any case the decision
that causes the unexpected behavior was not made by MS.
Secondly, the unexpected behavior is most certainly a consequence of
implementation done by one of those teams.
Nope, the failure to set ShowInTaskbar to false creates a path the user can
take. The result of the user taking that path is the unexpected behavior occurs.
First of all, you need to look at the documentation you are referring to
more closely.
You should read the documentation rather than just look at it. From
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
The window for which it sets ShowInTaskbar is not the parent
window, but rather the dialog being shown. The problem being discussed
here deals with the parent window, not the dialog being shown.
You are incorrect. As described by the OP the unexpected behavior occurs between
modal windows. A non-modal form will not be activated until the ShowDialog
method it called returns.
Yes, sometimes a programmer does not want dialogs to show up in the
taskbar. So yes, that's a use case for the property that comes up in an
EXAMPLE piece of code. But that does not mean that dialogs necessarily
must have that property set to false before being shown.
Not must but should. In the OP's scenario of not setting ShowInTaskbar to false
presents a path to unexpected behavior.
You are once again, without any justification at all, conflating the
ShowInTaskbar setting with the window activation behavior.
Conflating ... I like that. Too bad it's not true.
If the property were named "ShowInTaskbarAndAllowActivation", then you'd
have a point. But it's not. The property is solely there to control
visibility in the task bar. That's it.
And from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
For a variety of reasons, but one obvious one is that the window, even if
it's not supposed to accept input, may still be presenting useful
information, and the user may even want to be able to view that information
in the thumbnail view shown by the taskbar.
In that case specialized behavior can be obtained via taskbar extensions.
The OP is not required to justify showing the modal window. The default is
that APIs should behave consistently. It requires effort to justify
inconsistently, not the other way around.

There is no API for nested modal windows and certainly no documentation of how
they should behave when a window can be both modal or not at the same time.
If you're going to argue that a property named "ShowInTaskbar" is actually
also supposed to be used in lieu of a property named "AllowActivation", you
are the who needs to provide some actual justification.
And again from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
Repeatedly claiming a property named one thing is INTENDED to be used for
something else is not "actual justification". You need to present actual
facts.
And again from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
The point here is that it is NOT desired that Form2 can be activated while
Form3 is displayed. So far, so good.
This quote is out of context. Selective editing demonstrates nothing more than
the ability to copy and paste.
Incorrect. The default is "true" and when set to "true", the UNDESIRED
behavior occurs.

Let's assume you misspoke and meant to write "set to false". Then what you
wrote is true, but irrelevant. I already acknowledged that as a viable
work-around, for programs for which it is acceptable to not show Form2 in
the taskbar. We are not in disagreement on that point.
No let's just say the quote was taken out of context, which it was. As such it
serves no purpose.
Why? It is correct that doing so _can_ achieve that effect. But you have
completely failed to justify the claim that that is THE CORRECT WAY to
achieve that effect, as well as the claim that it's actually intentional
that one should have to. You just keep stating that over and over as if
it's fact.
Perhaps because it is fact. And yet again from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
Here are the relevant questions in my original post which you completely
ignored (I suppose because answering them would be too awkward while still
holding to your current position):
And yet again from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -
You can keep trying to defend the behavior, but your argument just doesn't
hold water. Your claim that a property named "ShowInTaskbar" is actually
_intentionally_ designed to accomplish some other completely unrelated goal
is just plain unfounded, and you continue to fail to provide any evidence
or logical discussion that would support it.
And finally from
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

- end quote -

Do you think the Microsoft documentation is sufficient proof? Are the nested
dialogs that follow VS's File|Open menu selection subject to the unexpected
behavior the OP sees? If not, why not? What is the ShowInTaskbar property used
for?

A little RTFM goes a long way in avoiding incorrect assumptions. From NET 1.1 on
the documentation explicitly states "You can use this property to prevent users
from selecting your form through the Windows taskbar." Is that sentence a little
familiar by now?

The documentation also contains examples in VB, C# and C++ each with an explicit
comment about setting ShowInTaskbar to false prior to calling ShowDialog.
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

// Do not allow form to be displayed in taskbar.

-end quote -

Would you care to re-evaluate your assumption concerning the intended use of the
ShowInTaskbar property?

regards
A.G.
 
R

Registered User

[...]
Although there is no mention of overloading, the statement you desire can be
found at
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>

- quote -

You can use this property to prevent users from selecting your form through the
Windows taskbar.

Sorry...I got bored after the fifth or sixth time you quoted that. It
appears that your reply consistts of practically nothing else. Hint:
saying the same irrelevant thing over and over again doesn't help make it
more relevant, nor does it address the question I posed.
I was accused of, in your words, "conflating the ShowInTaskbar setting with the
window activation behavior." You kept questioning my statements about how to use
the ShowInTaskbar property with modal windows. You kept asking where in the
documentation any mention was made about the ShowInTaskbar property being used
to prevent a window from being selected via the taskbar. I have provided the
documentation and now you say it's not relevant. I suppose Petzold probably
isn't relevant either. That's a real pissa.
"You CAN use this..." is not the same as "the intended design is that you
MUST use this to achieve rational user-interface behavior".
Can and must are not equivalents but so what? The onus is on the designer and
developer to use the tools correctly to present a rational UI. How much
hand-holding is necessary?
Fact: there are legitimate reasons for the user to generally want their
modal dialog window to be visible and selectable in the task bar. Visible
even in cases when the window itself should not receive activation.
I've heard no reasoning, citations or examples, just mumbling about taskbar
previews being necessary for modal windows. What sort of convoluted situation
would call for any window to have a taskbar entry without activation being
possible? lease point me to :
1 - a real world example of this behavior
2 - the MS documentation which indicates this is an intended design and use of
taskbar entries
Fact: in most cases, when a modal dialog is present, selecting other
windows that are non-activateable while the dialog is visible causes the
modal dialog to become active, not the others. Just as one might expect.
Yes this is normal behavior between the top-level window and a modal window, so
what? The OP's issue involved unexpected behavior between supposedly modal
dialogs. I pointed out how to use the ShowInTaskbar property to avoid the issue.
Simple problem, simple solution, Occam's razor.
Conclusion: it is a clearly logical conclusion that it is not intentional
behavior that in a narrow, specific scenario, selecting a window via the
taskbar allows that window to be momentarily activated and for a specific
kind of input to leak through, even though almost every other kind of input
is still prohibited.
It simply makes no logical sense that's intended.
Yes it is not intentional behavior but there is a need to understand what
defines a modal window. "A modal dialog box requires the user to close the
dialog box before activating another window in the application." Need a
citation? What the OP considered to be modal windows weren't. That created the
path to the unexpected behavior. Setting the ShowInTaskbar property to false
just as described in the MS documentation made the windows truly modal.
As a programmer, I deal in logic.

Do you remember writing this in your previous post?

- quote -
You are once again, without any justification at all, conflating the
ShowInTaskbar setting with the window activation behavior.

If the property were named "ShowInTaskbarAndAllowActivation", then you'd
have a point. But it's not. The property is solely there to control
visibility in the task bar. That's it.
- end quote -

The documentation clearly states the relationship between the ShowInTaskbar
property and window activation. Your logic failed to note that if a window is
not shown in the taskbar, it cannot be selected from the taskbar.
The inherent contradictions in your
position make it clear to me it's not valid.

Inherent contradictions? Not valid? All I've done is make reference to readily
available documentation regarding a form's ShowInTaskbar property and its usage
with modal dialogs. What you called a "moderately serious bug in .NET" was
simply the result of not using the tools correctly.
If you want to continue
holding your view in spite of lacking any evidence in support of it,

My view? All I tried to do was provide a simple solution to the OP's problem
just as described in the MS documentation. You took exception to the proper use
of ShowInTaskbar with modal windows and here we are.
be my
guest. I'm done wasting my time trying to explain it.

Your explanation? It doesn't work the way you think it should so it must be a
bug. I'd expect that from Ray Lopez but not a MS MVP.

regards
A.G.
 
R

Registered User

Hi, everyone.

I have a weird problem of nested ShowDialog() behavior.
I believe that the ShowDialog mothod shows a Form as a modal dialog,
so you can not perform any action on any other Forms until you close
the modal dialog.
But I found the way to violate this rule.

Let's say there are 3 forms; TopForm, SecondForm and ThirdForm.
Like this...

static class Program
{
[STAThread]
static void Main()
{
Application.Run(new TopForm());
}
}

public class TopForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
SecondForm form = new SecondForm();
form.ShowDialog(this);
}
}

public class SecondForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
ThirdForm form = new ThirdForm();
form.ShowDialog(this);
}
}

Do the following steps.
1.Click the button on TopForm to create the SecondForm
2.Click the button on the SecondForm to create the ThirdForm.
3.You can now see the 3 Forms are shown.
4.Click the button on the taskbar for the SecondForm, you can see the
SecondForm is focused.
5.Simply push the button on the SecondForm by pushing the enter key.
6.Now you have two ThirdForms.

Assume that the ThirdForm is exit-confirming dialog, and popuped
multiply.
This is problem, and I don't like this behavior.
I'd like them to work when i click the button on the task bar for the
SecondForm simply to bring the ThirdForm to top-most or so...
Any suggestions are really grateful.
There appears to be some confusion about what modal and modeless dialogs are and
how to display a form modally using .NET.

The Dialog Boxes Overview at
<http://msdn.microsoft.com/en-us/library/aa969773.aspx>
notes a modal dialog box prevents a user from activating other windows in the
application while it remains open. A modeless dialog box does not prevent a user
from activating other windows while it is open

The Form type's ShowDialog method is overloaded.
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showdialog.aspx>
The documentation for ShowDialog() states "Shows the form as a modal dialog
box." The 'as' represents a key distinction in that sentence. Calling the method
doesn't make the form modal, the form is shown as if it is modal.

The overloaded version of the method takes an IWin32Window implementation as an
argument. The documentation for the method states "Shows the form as a modal
dialog box with the specified owner." A comment about the parameter is "Any
object that implements IWin32Window that represents the top-level window that
will own the modal dialog box. "

In the code shown above form3 does not qualify as a modal form. Although form3
is displayed as if it is modal, form2 can be activated from the taskbar. This
makes form3 by definition a modeless dialog. This occurs even though the
overloaded ShowDialog method is called because form2 is not a top-level window.

To make form3 truly modal, the user must not be able to activate form2 from the
taskbar. This leads to the Form type's ShowInTaskbar property.
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar.aspx>
One thing to note is the remark "If a form is parented within another form, the
parented form is not displayed in the Windows taskbar." This helps clarify how
the overloaded ShowDialog uses the IWin32Window implementation.

The documentation states the ShowInTaskbar property can be used to prevent users
from selecting your form through the Windows taskbar. In the code above setting
form2's ShowInTaskbar property to false makes form3 fit the definition of a
modal dialog.

Peter Duniho questioned where the documentation indicated the ShowInTaskbar
property must be used for forms to behave modally. There is no must because
there are at least three ways to make a form behave modally and two of them do
not use the ShowInTaskbar property.

The overloaded ShowDialog method can be used :
Form2 form2 = new Form2();
// this pointer is a top-level window
form2.ShowDialog(this);

The Owner property can be set :
Form2 form2 = new Form2();
// this pointer is a top-level window
form2.Owner = this;
form2.ShowDialog();

The ShowInTaskbar property can be set :
Form2 form2 = new Form2();
form2.ShowInTaskbar = false;
form2.ShowDialog();

When showing a form modally I prefer to explicitly set the ShowInTaskbar
property to false before calling ShowDialog. Doing so eliminates the dependency
of a 'this' pointer pointing to a top-level window. It is this failed dependency
that opens the path the unexpected behavior the OP has experienced.

regards
A.G.
 
R

Registered User

Hi, everyone.

I have a weird problem of nested ShowDialog() behavior.
I believe that the ShowDialog mothod shows a Form as a modal dialog,
so you can not perform any action on any other Forms until you close
the modal dialog.
But I found the way to violate this rule.

Let's say there are 3 forms; TopForm, SecondForm and ThirdForm.
Like this...

static class Program
{
[STAThread]
static void Main()
{
Application.Run(new TopForm());
}
}

public class TopForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
SecondForm form = new SecondForm();
form.ShowDialog(this);
}
}

public class SecondForm : Form
{
private void button1_Click(object sender, EventArgs e)
{
ThirdForm form = new ThirdForm();
form.ShowDialog(this);
}
}

Do the following steps.
1.Click the button on TopForm to create the SecondForm
2.Click the button on the SecondForm to create the ThirdForm.
3.You can now see the 3 Forms are shown.
4.Click the button on the taskbar for the SecondForm, you can see the
SecondForm is focused.
5.Simply push the button on the SecondForm by pushing the enter key.
6.Now you have two ThirdForms.

Assume that the ThirdForm is exit-confirming dialog, and popuped
multiply.
This is problem, and I don't like this behavior.
I'd like them to work when i click the button on the task bar for the
SecondForm simply to bring the ThirdForm to top-most or so...
Any suggestions are really grateful.
There appears to be some confusion about what modal and modeless dialogs are and
how to display a form modally using .NET.

The Dialog Boxes Overview at
<http://msdn.microsoft.com/en-us/library/aa969773.aspx>
notes a modal dialog box prevents a user from activating other windows in the
application while it remains open. A modeless dialog box does not prevent a user
from activating other windows while it is open

The Form type's ShowDialog method is overloaded.
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showdialog.aspx>
The documentation for ShowDialog() states "Shows the form as a modal dialog
box." The 'as' represents a key distinction in that sentence. Calling the method
doesn't make the form modal, the form is shown as if it is modal.

The overloaded version of the method takes an IWin32Window implementation as an
argument. The documentation for the method states "Shows the form as a modal
dialog box with the specified owner." A comment about the parameter is "Any
object that implements IWin32Window that represents the top-level window that
will own the modal dialog box. "

In the code shown above form3 does not qualify as a modal form. Although form3
is displayed as if it is modal, form2 can be activated from the taskbar. This
makes form3 by definition a modeless dialog. This occurs even though the
overloaded ShowDialog method is called because form2 is not a top-level window.

The last sentence is incorrect. It should read:
This occurs even though the overloaded ShowDialog method is called
 
R

Registered User

The sentence following the quoted portion above is:

A modeless dialog box does not prevent a user
from activating other windows while it is open
Well, it's supposed to. But in the bug reported by the OP, it does not.
That's the whole point of this discussion.
The design of the application makes what should be a modal window behave as if
it were modeless. Without being dismissed a modal window can lose focus to its
modal window parent.
[...]
The Form type's ShowDialog method is overloaded.
<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.showdialog.aspx>
The documentation for ShowDialog() states "Shows the form as a modal dialog
box." The 'as' represents a key distinction in that sentence. Calling the method
doesn't make the form modal, the form is shown as if it is modal.

You're drawing a false distinction. The only thing that really makes a
form (or any window) "modal" is how it's displayed. The exact same Form
class instance can be used modally or modelessly, and that is the _only_
way to invoke that difference.

A Form instance in and of itself is neither modal nor modeless. It only
ever becomes one or the other if and when it's shown, and does so based on
how it's shown.
[...]
In the code shown above form3 does not qualify as a modal form. Although form3
is displayed as if it is modal, form2 can be activated from the taskbar. This
makes form3 by definition a modeless dialog. This occurs even though the
overloaded ShowDialog method is called because form2 is not a top-level window.

Please. Stop posting on this topic until you have done a better job
understanding the Windows windowing model.

Your confusion is understandable, because of the terminology used in the
model. But it's very important to understand: "top-level" simply means the
window has no parent window. For example, a Form class instance is usually
a top-level window. The only exception is for MDI child windows.

This is not the same as the question of whether a window has an _owner_ or
not. A top-level window can still have an owner.

Your statement that "form2 is not a top-level window" is simply wrong.
Having no parent window, it absolutely is.
I was incorrect to write that form2 is not a top-level window, the form is
displayed as a top-level window by virtue of being owned by the main form in the
OP's example. We're both incorrect.
There are a great many references that can help you clear up your
misunderstandings. I recommend you start here:
http://msdn.microsoft.com/en-us/library/ms632597(v=vs.85).aspx#parent_owner_handle

Your other claims about modality, activation rules, etc. are similarly
mistaken,

These alleged claims can all be found in the documentation and citations were
provided. That includes the ShowInTaskbar property being used to prevent windows
from being activated via the taskbar. You wrote if that were the case the
property should be named "ShowInTaskbarAndAllowActivation". You asked

- direct quote -

Where does Microsoft state that its function is overloaded to also include
preventing the window from being activated?

- end quote -

and I provided a link to the MS documentation. In your next post you claimed the
property's usage to be irrelevant WRT the bug you claim exists. You wanted to
see must instead of can.

The window showing itself _as_ being modal has no control over its usage and
environment. The application allows nested modal dialogs each to have their own
taskbar entry creating a side-effect. The side-effect makes it possible for a
modal dialog to lose focus when a taskbar entry is selected. The application's
design permits other application windows to be selected via the taskbar even
though the application has a modal window open.

The OP's code may not work as desired but it certainly works just exactly as
designed. Changing a single form property, as shown in the documentation, before
displaying the form modally brings about the desired behavior.
but I have spent enough time on those already.

All you've done is try to convince me that modal windows need to have their own
taskbar entries. In the OP's code those taskbar entries allow a modal window to
lose focus to its modal parent window.
You are doing
this newsgroup, its readers, and the C#/.NET community itself a great
disservice by continuing to pursue this misguided defense of what is
clearly a bug in some layer of the windowing system (whether in .NET or the
underlying Windows API).
The disservice comes when you attack the messenger and misquote the message.
Your focus has been on what happens _after_ the modal form loses scope rather
than _why_ the modal form loses scope. What you call a bug is nothing more than
an elementary design/implementation error.

regards
A.G.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top