System.ArgumentException on close when dialog not on top [Compact Framework]

Prev: refresh flicker even w/ double buffering
Next: BvE Drivers Firmware R4i, R4 Sdhc, M3i Zero, EzFlash Vi Dsi. XA!

From: Chris Tacke, MVP on 27 Aug 2009 16:03

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

"Lcubed" <loris.emailbox(a)gmail.com> wrote in message
news:8740f1f1-9c21-49e4-a78f-7375f21b582f(a)c34g2000yqi.googlegroups.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

On Aug 27, 12:10 pm, "Paul G. Tobey [eMVP]" wrote:
> 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:90D4A41E-6DA9-4C4C-8949-BEA667EF36CC(a)microsoft.com...
>
> > 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
>
> > "Lcubed" <loris.email...(a)gmail.com> wrote in message
> >news:8c45d35c-c932-494a-9d04-6fc9f721e9a1(a)r33g2000vbp.googlegroups.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]" > 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.
>
> >> "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> >>news:d77034db-e278-4f3b-91cc-aaee92d24094(a)s13g2000yql.googlegroups.com...
> >> 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]" >> 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.
>
> >> > "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> >> >news:39531cc9-37de-45b7-a380-b52304a338ba(a)e34g2000vbm.googlegroups.com...
> >> > 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]" >> > 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.
>
> >> > > "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> >> > >news:e4d9a959-fe1c-4431-a1eb-ef1d69353238(a)l5g2000yqo.googlegroups.com...
>
> >> > > >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.

From: Lcubed on 22 Sep 2009 15:42

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

On Aug 27, 4:03 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
> 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
>
> "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> news:8740f1f1-9c21-49e4-a78f-7375f21b582f(a)c34g2000yqi.googlegroups.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
>
> On Aug 27, 12:10 pm, "Paul G. Tobey [eMVP]" no instrument no spam DOT com> wrote:
>
> > 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:90D4A41E-6DA9-4C4C-8949-BEA667EF36CC(a)microsoft.com...
>
> > > 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
>
> > > "Lcubed" <loris.email...(a)gmail.com> wrote in message
> > >news:8c45d35c-c932-494a-9d04-6fc9f721e9a1(a)r33g2000vbp.googlegroups.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]" > > 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.
>
> > >> "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> > >>news:d77034db-e278-4f3b-91cc-aaee92d24094(a)s13g2000yql.googlegroups.com...
> > >> 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]" > >> 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.
>
> > >> > "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> > >> >news:39531cc9-37de-45b7-a380-b52304a338ba(a)e34g2000vbm.googlegroups.com...
> > >> > 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]" > >> > 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.
>
> > >> > > "Lcubed" <loris.email...(a)gmail.com> wrote in message
>
> > >> > >news:e4d9a959-fe1c-4431-a1eb-ef1d69353238(a)l5g2000yqo.googlegroups..com...
>
> > >> > > >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.

First | Prev |
Pages: 1 2 3
Prev: refresh flicker even w/ double buffering
Next: BvE Drivers Firmware R4i, R4 Sdhc, M3i Zero, EzFlash Vi Dsi. XA!