System.ArgumentException on close when dialog not on top

[Lcubed]

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.

 

[Paul G. Tobey [eMVP]]

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.

 

[Lcubed]

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!

 

[Paul G. Tobey [eMVP]]

And it's a child of the one you're trying to close? Perhaps that's an 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!

 

[Lcubed]

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.

 

[Paul G. Tobey [eMVP]]

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.

 

[Lcubed]

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.

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.

And it's a child of the one you're trying to close? Perhaps that's an area
that could be done another way. I would guess that, since you're tryingto
close the parent of an active window without closing that window, you're
establishing a condition where the child does something via a referenceto
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.

"Lcubed" <[email protected]> wrote in message

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.

 

[Chris Tacke, MVP]

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.

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.

And it's a child of the one you're trying to close? Perhaps that's an
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.

"Lcubed" <[email protected]> wrote in message

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.

 

[Paul G. Tobey [eMVP]]

You should have only *one* thread, the UI thread, launching windows. If you
try to have a non-UI thread do UI, you've broken the user interface of
Windows CE and the behavior is no longer predictable.

Paul T.

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.

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.

And it's a child of the one you're trying to close? Perhaps that's an
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.

"Lcubed" <[email protected]> wrote in message

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.

 

[Lcubed]

Timers don't count as threads, do they? The UI is only one thread.

so the code goes something like this

(all in form1)
button_click
showdialog confirm (dialog has a timeout after a minute if no
response)

timer
check hardware
if hardware error showdialog alert

You should have only *one* thread, the UI thread, launching windows.  If you
try to have a non-UI thread do UI, you've broken the user interface of
Windows CE and the behavior is no longer predictable.

Paul T.

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.

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's an
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.

 

[Chris Tacke, MVP]

Depends on the type of Timer used. If it's a System.Threading.Timer, then
yes, it is a spearate thread. If it's a System.Windows.Forms.Timer, then it
fires on the main UI thread already, and provided the first ShowDialog
happened on the same thread, it won't pop up until the first is dismissed.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


Timers don't count as threads, do they? The UI is only one thread.

so the code goes something like this

(all in form1)
button_click
showdialog confirm (dialog has a timeout after a minute if no
response)

timer
check hardware
if hardware error showdialog alert

You should have only *one* thread, the UI thread, launching windows. If
you
try to have a non-UI thread do UI, you've broken the user interface of
Windows CE and the behavior is no longer predictable.

Paul T.

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.

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's an
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.

 

[Lcubed]

Just in case anyone else is having this issue, it is a bug, I found it
here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=328786

Depends on the type of Timer used.  If it's a System.Threading.Timer, then
yes, it is a spearate thread.  If it's a System.Windows.Forms.Timer, then it
fires on the main UI thread already, and provided the first ShowDialog
happened on the same thread, it won't pop up until the first is dismissed..

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded communityhttp://community.OpenNETCF.com


Timers don't count as threads, do they? The UI is only one thread.

so the code goes something like this

(all in form1)
button_click
      showdialog confirm (dialog has a timeout after a minute if no
response)

timer
     check hardware
     if hardware error showdialog alert

You should have only *one* thread, the UI thread, launching windows. If
you
try to have a non-UI thread do UI, you've broken the user interface of
Windows CE and the behavior is no longer predictable.

Paul T.

"Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> wrote in
messagenews:[email protected]...

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.