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.
Where does Microsoft state that its function is overloaded to also include
preventing the window from being activated?
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
enough, shows another modal dialog.
Your claim that there is a program design or implementation error just
because there are nested modal dialogs is a complete non-starter.
First of all, Microsoft headquarters is in Redmond, WA. The Windows and
.NET dev teams remain there, at least for now.
Secondly, the unexpected behavior is most certainly a consequence of
implementation done by one of those teams.
First of all, you need to look at the documentation you are referring to
more closely. 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.
Yes, sometimes a programmer does not want dialogs to show up in the
taskbar. So yes, that is 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.
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 would
have a point. But it is not. The property is solely there to control
visibility in the task bar. That's it.
For a variety of reasons, but one obvious one is that the window, even if
it is 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.
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.
If you are 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.
Repeatedly claiming a property named one thing is INTENDED to be used for
something else is not "actual justification". You need to present actual
The point here is that it is NOT desired that Form2 can be activated while
Form3 is displayed. So far, so good.
Incorrect. The default is "true" and when set to "true", the UNDESIRED
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.
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 is actually intentional
that one should have to. You just keep stating that over and over as if
it is fact.
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):
You can keep trying to defend the behavior, but your argument just does not
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.