PC Review


Reply
Thread Tools Rating: Thread Rating: 3 votes, 2.33 average.

Weird problem of nested ShowDialog() behavior

 
 
momonga
Guest
Posts: n/a
 
      16th Mar 2012
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!!!!





 
Reply With Quote
 
 
 
 
Jeff Johnson
Guest
Posts: n/a
 
      16th Mar 2012
"momonga" <(E-Mail Removed)4u.or.jp> wrote in message
news:(E-Mail Removed)...

> public class SecondForm : Form
> {
> private void button1_Click(object sender, EventArgs e)
> {

try
{
Enabled = false;
> ThirdForm form = new ThirdForm();
> form.ShowDialog(this);

}
finally { Enabled = true; }
> }
> }




 
Reply With Quote
 
 
 
 
momonga
Guest
Posts: n/a
 
      16th Mar 2012
Thanks a lot Jeff!!!!!!!!
it works really fine!

 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      17th Mar 2012
On Fri, 16 Mar 2012 07:12:28 -0700 (PDT), momonga <(E-Mail Removed)4u.or.jp>
wrote:

>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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      17th Mar 2012
On Fri, 16 Mar 2012 23:58:36 -0700, Peter Duniho <(E-Mail Removed)>
wrote:

>On Sat, 17 Mar 2012 01:14:01 -0400, Registered User wrote:
>
>> 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.

>
>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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      17th Mar 2012
On Sat, 17 Mar 2012 10:17:50 -0700, Peter Duniho <(E-Mail Removed)>
wrote:

>On Sat, 17 Mar 2012 12:03:17 -0400, Registered User wrote:
>
>> [...]
>>>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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      18th Mar 2012
On Sat, 17 Mar 2012 14:47:44 -0700, Peter Duniho <(E-Mail Removed)>
wrote:

>On Sat, 17 Mar 2012 17:13:40 -0400, Registered User wrote:
>
>> If the intention isn't to permit form2 to receive focus, the form's
>> ShowInTaskbar property should be set to false.

>
>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 -

>>>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.

>
>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 -

>>>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.
>>>

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 -

>> The decision that causes the unexpected behavior was not made in Bellevue.

>
>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.

>> 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.

>
>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 -

>>>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?

>
>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
>> 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 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 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.

>
>The point here is that it is NOT desired that Form2 can be activated while
>Form3 is displayed. So far, so good.
>
>> If form2's
>> ShowInTaskbar property is set to true, the desired behavior will be achieved.

>

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.

>> If form2 shouldn't receive focus until form3 is dismissed, its ShowInTaskbar
>> property should be set to false before form2.ShowDialog is invoked.

>
>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):
>
>> 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?

>
>And:
>
>> 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.

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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      19th Mar 2012
On Sun, 18 Mar 2012 12:18:29 -0700, Peter Duniho <(E-Mail Removed)>
wrote:

>On Sat, 17 Mar 2012 20:16:59 -0400, Registered User wrote:
>
>> [...]
>> 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 ****a.

>"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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      20th Mar 2012
On Fri, 16 Mar 2012 07:12:28 -0700 (PDT), momonga <(E-Mail Removed)4u.or.jp>
wrote:

>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.
 
Reply With Quote
 
Registered User
Guest
Posts: n/a
 
      20th Mar 2012
On Tue, 20 Mar 2012 02:47:21 -0400, Registered User <(E-Mail Removed)> wrote:

>On Fri, 16 Mar 2012 07:12:28 -0700 (PDT), momonga <(E-Mail Removed)4u.or.jp>
>wrote:
>
>>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
>
>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.

 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
really weird behavior, chart with textbox font size problem xlrotor Microsoft Excel Programming 1 26th Feb 2008 11:11 PM
weird weird weird... multiple text boxes alves Microsoft Powerpoint 6 12th Oct 2007 04:53 PM
weird problem[?] annoyance with "Send/Receive" behavior and the Outbox albert Microsoft Outlook 5 18th Oct 2006 02:47 PM
Very weird problem using NotifyIcon and Context Menu for MSN like form/app closing behavior ThunderMusic Microsoft Dot NET 3 18th Aug 2005 10:11 AM
Very weird problem using NotifyIcon and Context Menu for MSN like form/app closing behavior ThunderMusic Microsoft VB .NET 3 18th Aug 2005 10:11 AM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 06:06 AM.