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.
