.NET Framework - Weird problem of nested ShowDialog() behavior

Asked By momonga on 16-Mar-12 10:12 AM
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 do not 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!!!!




Jeff Johnson replied to momonga on 16-Mar-12 10:59 AM
try
{
Enabled = false;
}
finally { Enabled = true; }
momonga replied to Jeff Johnson on 16-Mar-12 11:41 AM
Thanks a lot Jeff!!!!!!!!
it works really fine!
Peter Duniho replied to momonga on 16-Mar-12 08:41 PM
Nor should you!  IMHO, this is a moderately serious bug in .NET.  For
future reference, when you come across something like this, please report
it on Microsoft's Connect web site, if it has not been reported already.

As it happens, someone else has in fact reported something quite similar
(not exactly the same scenario, but definitely the same root cause):
https://connect.microsoft.com/VisualStudio/feedback/details/581382/windows-taskbar-can-activate-a-non-modal-window-when-a-modal-window-is-active-wpf-winforms#

I went ahead and added my own commentary, including a summary of what is
been discussed here.

Of course, given the current status of Forms, and of .NET generally, it is
entirely possible they will just blow the bug off.  But at least it is been
reported.  :)


Jeff's solution is not bad, but it could have unintended visual
consequences.  Disabling the entire form is not always what you want the
user to see.

I think that a better approach would be to have any form that is not
top-most return focus to the top-most form if it receives focus itself.
Here is an example of code that does this sort of thing, in the form of an
extension method:

public static void SafeShowDialog(this Form dialog, Form parent)
{
EventHandler handler = (sender, e) =>
{
dialog.Activate();
};

try
{
parent.Activated += handler;
dialog.ShowDialog(parent);
}
finally
{
parent.Activated -= handler;
}
}

As an extension method, you can just change calls like this:

using (MyDialog dialog = new MyDialog())
{
dialog.ShowDialog(this);
}

to this:

using (MyDialog dialog = new MyDialog())
{
dialog.SafeShowDialog(this);
}

Of course, the non-extension syntax works fine too:

using (MyDialog dialog = new MyDialog())
{
Extensions.SafeShowDialog(dialog, this);
}

By the way, note the use of "using" in the above code.  For Form instances
shown using ShowDialog() it is important to use "using" or otherwise ensure
that the instance is disposed.  Form instances are only automatically
disposed on close for NON-modal forms.

Pete
Frank replied to Peter Duniho on 16-Mar-12 11:42 PM
Hell, i better look over my codes. Is that a bug or is it 'by design' ?
I'd have thought we normally pop a modal dialog to get user input, then
harvest whatever we need back from it when we get execution back. Once the
procedure(we called it from) exits, the dialog should have no place
persisting.
Or am i missing something here ?

--

Regards, Frank
Frank replied to momonga on 17-Mar-12 12:41 AM
If you can spare a class level variable, this may be another workaround to
look at:

public class SecondForm : Form
{
ThirdForm form = null;

private void button1_Click(object sender, EventArgs e)
{
if(null == ThirdForm)
{
ThirdForm form = new ThirdForm();
form.ShowDialog(this);
//dosomething
form.Dispose(); // because Peter said so. ;)
form = null;
}
else
form.focus();
}
}

It does not disable the 2nd form, but it is still fugly.

Of course, you could also just set ShowInTaskbar to false for Form2 and be
done with it. :-)

--

Regards, Frank
Registered User replied to momonga on 17-Mar-12 01:14 AM
form.ShowInTaskbar = false;
form.ShowInTaskbar = false;

Setting the modal forms' ShowInTaskbar property to false will eliminate the
issue. it is 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.
Peter Duniho replied to Frank on 17-Mar-12 02:56 AM
it is by design.  A typical use case by far is for data to be retrieved from
a modal dialog after it is been closed (indeed, closing the dialog is the
signal that the user is done with it).  If the dialog were to be disposed
when closed, then every time you created a modal dialog, you would have to
copy every possible value from all the controls to some other location, so
that the data is still available.

Not only would that be a huge pain, it would mean that there would be a
major structural difference between a modal dialog and modeless form,
rather than just the difference in how they are shown.

So instead, modal dialogs do not get disposed, and that way the data can
simply be retrieved as needed from whatever controls exist in the dialog.


See above.  If the dialog were disposed as soon as it was closed, you
could not "harvest" the data from the dialog when the ShowDialog() method
returns.

Pete
Peter Duniho replied to Registered User on 17-Mar-12 02:58 AM
Except that it does not.  Most user input is still disabled, even though the
form has been activated.  You cannot click on the button.  You cannot even
use the space bar to select it, as you would be able to if the form were
truly active.  There is just this odd little loophole that lets a particular
kind of input (the Enter key) get through.

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

Pete
Registered User replied to Peter Duniho on 17-Mar-12 12:03 PM
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


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 should not have
focus at the same time.

regards
A.G.
Peter Duniho replied to Registered User on 17-Mar-12 01:17 PM
I disagree with your assessment that "the UI portion of the design
INTENTIONALLY permits form2 to receive focus..."

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 is intentional
that the window that does not receive input can still be made active via the
taskbar, then it is a bug that you cannot activate EVERY window via the
taskbar.

One way or the other, there is 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 is not now?

(I also find your distinction between "programmatically...denies focus" and
so to think that there is any sort of non-UI consideration at play, as your
distinction appears to imply, is really odd).

I really do not think it is intentional. It makes no sense that any but the
active, modal dialog could be activated, and indeed this is how the simpler
scenarios work.

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 is
useful to be able to cause a window that is not accepting user input to
become the active window), I see no reason to believe that the behavior is
intentional.

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 is every reason to want to keep the window there, even when the the
window itself should not be accessible.

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.

Pete
Registered User replied to Peter Duniho on 17-Mar-12 05:13 PM
If the intention is not to permit form2 to receive focus, the form's
ShowInTaskbar property should be set to false.

I see the problem as an artifact of cascading modal forms and a failure to
properly set the ShowInTaskbar property before invoking ShowDialog.


One action is performed programmatically while the other results from user
interaction. That is not a subtle distinction. When unintended paths exist users
will find them sooner rather than later.

Agreed but simpler scenarios do not 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.

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.

Why choose to permit the window to be accessible when it should not 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.

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 should not 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 do not 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.
Peter Duniho replied to Registered User on 17-Mar-12 05:47 PM
Says who?

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


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


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


And:


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.

Pete
Registered User replied to Peter Duniho on 17-Mar-12 08:16 PM
Who says not? Have you ever seen the sentences
through the Windows taskbar."
and
on the same page of .NET documentation?

Are you absolutely certain in your assumptions regarding the ShowInTaskbar
property?

Although there is no mention of overloading, the statement you desire can be
found at

- quote -

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

- end quote -

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

- quote -

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

- end quote -

OK again from

- quote -

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

- end quote -

Many projects cross the border between the two towns. In any case the decision
that causes the unexpected behavior was not made by MS.

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.

You should read the documentation rather than just look at it. From

- quote -

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

- end quote -

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.

Not must but should. In the OP's scenario of not setting ShowInTaskbar to false
presents a path to unexpected behavior.

Conflating ... I like that. Too bad it is not true.

And from

- quote -

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

- end quote -

In that case specialized behavior can be obtained via taskbar extensions.


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.

And again from

- quote -

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

- end quote -
And again from

- quote -

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

- end quote -
This quote is out of context. Selective editing demonstrates nothing more than
the ability to copy and paste.

No let us just say the quote was taken out of context, which it was. As such it
serves no purpose.

Perhaps because it is fact. And yet again from

- quote -

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

- end quote -
And yet again from

- quote -

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

- end quote -
And finally from

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

- 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.
Peter Duniho replied to Registered User on 18-Mar-12 03:18 PM
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 does not help make it
more relevant, nor does it address the question I posed.

MUST use this to achieve rational user-interface behavior".

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.

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.

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

As a programmer, I deal in logic.  The inherent contradictions in your
position make it clear to me it is not valid.  If you want to continue
holding your view in spite of lacking any evidence in support of it, be my
guest.  I am done wasting my time trying to explain it.

Pete
Registered User replied to Peter Duniho on 18-Mar-12 09:00 PM
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 is not relevant. I suppose Petzold probably
is not relevant either. That's a real pissa.

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?

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

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.

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


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 would
have a point.  But it is 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.


Inherent contradictions? Not valid? All I have 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.


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.


Your explanation? It does not 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.
Registered User replied to momonga on 20-Mar-12 02:47 AM
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
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.
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
does not 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.
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.
Peter Duniho replied to Registered User on 20-Mar-12 04:06 AM
Well, it is supposed to.  But in the bug reported by the OP, it does not.
That's the whole point of this discussion.


You're drawing a false distinction.  The only thing that really makes a
form (or any window) "modal" is how it is 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 is shown, and does so based on
how it is shown.


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

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, but I have spent enough time on those already.  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).

Pete
Registered User replied to Registered User on 20-Mar-12 03:10 PM
The last sentence is incorrect. It should read:
This occurs even though the overloaded ShowDialog method is called
Registered User replied to Peter Duniho on 20-Mar-12 03:10 PM
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

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.

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.


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.


All you have 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.

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.