So you have something calling ShowDialog out on a worker thread
somewhere
(it's the only way 2 ShowDialog calls can happen without one being a
child
of the other)? Therein lies the problem - that's a bad design decision.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
They are both ShowDialog. One is just a confirmation with a timeout
but the other is an event that happens when our external hardware is
in a state that should only take place when nothing else is going on
so this is rare. The confirmation and timeout are both needed. Since
the user needs an alert on the aforementioned hardware state, I used
an event to trigger the dialog.
On Aug 26, 6:11 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
How are you loading those "dialogs"? They can't both be ShowDialog(),
so
what's the story? Or, if you think they are both ShowDialogs, how are
you
accomplishing the launch of the second dialog while the first one is
processing?
Paul T.
No, I'm not trying to close the parent of a child. The parent for both
is the main dialog which I keep open for the duration of the app. It's
just an unrelated sibling
trying to close. It doesn't sound like
that is illegal. I've had other apps do the same thing. If an
unrelated window that is not on top tries to close, there is an
exception. I was hoping there might be something I'm missing.
On Aug 26, 5:44 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
And it's a child of the one you're trying to close? Perhaps that'san
area
that could be done another way. I would guess that, since you're
trying
to
close the parent of an active window without closing that window,
you're
establishing a condition where the child does something via a
reference
to
the parent that no longer contains sensible data, causing the
exception.
TopMost has nothing to do with parent-child relationships. I would
guess
that a dialog does not need to be "on top" of the window ordering to
close,
but I bet it can't be disabled and waiting for a child dialog of its
own
to
close when it goes away.
Paul T.
It's not as bad as all that. There's just one dialog that needs to
close and once in a blue moon another dialog is on top of it. But the
top dialog needs to be there. I have tried making the offending
dialog
the TopMost right before closing, but this does not work either.
However, that does answer my question, a dialog must be on top to
close, so I need to do something else.
Thanks!
On Aug 26, 5:22 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
So, you have potentially stacked-up dialogs where the middle ones
in
the
stack may closed as a result of a time-out? That seems like a poor
design,
but maybe you could notify all child forms that they should close
via
some
structure that you come up with and, when they've all done so, set
the
DialogResult.
Paul T.
I have timed dialogs that work great, except when there is another
window on top and the window that is not on top wants to close..
Then a
System.ArgumentException occurs with the message "An error
message
cannot be displayed because an optional resource assembly
containing
it cannot be found" I'm not missing any assemblies, if the dialog
is
on top, it closes fine.
Can anyone decipher this?
Here is the C# code where the exception occurs:
private System.Windows.Forms.Timer timerClose;
// ....
void tCloseDiag_tick(object sender, EventArgs e)
{
try
{
timerClose.Enabled = false;
this.DialogResult = DialogResult.Cancel;
}
catch (Exception ex)
{
// exception here
}
}
Any suggestions appreciated.
