| Groups | Blog | Home |
dotnet compact framework : MessageBox.Show Sometimes Locks my application
display a message to the user using MessageBox.Show(). However, depending on where the exception is caught, this sometimes locks my application. Specifically, I tried wrapping my Sub Main in try-catch blocks, and it blocked. I can understand how this would occur, since at that point it is no longer in the message pump and will not process messages. I tried to fix this by moving the try-catch up the call stack a level and put it in ApplicationEx.Pump(), like so: private static bool Pump() { ArrayList MyMessageFilters = new ArrayList(); // there are, so get the top one if (GetMessage(out msg, IntPtr.Zero, 0, 0)) { try { // the usual code goes here } catch (Exception ex) { MessageBox.Show("Exception: " & ex.Message); } } else { return false; } return true; } However, my application is still blocking when the catch is reached and MessageBox.Show is displayed. It seems like the message pump should continue, but it's not. Why not? Is there a best practice for where to put the outermost exception handler in a CF app?
[quoted text, click to view]
> (Although, wouldn't my app exit in that case?) Anyone have any ideas All threads in v1 are foreground threads. So if you do not take the steps necessary for your thread to exit, it will continue to run (thus keeping your process up even after the UI thread has exited). If you post a small repro we can have a look at it. Cheers Daniel -- http://www.danielmoth.com/Blog/ [quoted text, click to view] "Myron Marston" <guitar_melosh@hotmail.com> wrote in message
news:1122563791.359863.312220@z14g2000cwz.googlegroups.com... > Thanks for the quick reply, Daniel. I am aware of the lack of global > exception handling in the CF, having read that at your blog before > (which has been very helpful, by the way--this is my first CF project). > I don't believe this is scenario 3, and I am running SP3, so the issue > remains... > > There's one thing I've noticed that may give us a clue as to what's > going on: when this situation occurs while I'm debugging from VS and I > hit the pause button, it always breaks into a background thread, never > the main UI thread. Does this indicate that the UI thread has exited? > (Although, wouldn't my app exit in that case?) Anyone have any ideas > for how to figure out what's going on? >
Thanks for the quick reply, Daniel. I am aware of the lack of global
exception handling in the CF, having read that at your blog before (which has been very helpful, by the way--this is my first CF project). I don't believe this is scenario 3, and I am running SP3, so the issue remains... There's one thing I've noticed that may give us a clue as to what's going on: when this situation occurs while I'm debugging from VS and I hit the pause button, it always breaks into a background thread, never the main UI thread. Does this indicate that the UI thread has exited? (Although, wouldn't my app exit in that case?) Anyone have any ideas for how to figure out what's going on?
There is no global exception handling with netcf v1.0:
http://www.danielmoth.com/Blog/2004/08/global-exception-handling-net-cf-v10.html You might be in scenario 3 above in which case I think it got better with SP3 so make sure you are running that. Cheers Daniel -- http://www.danielmoth.com/Blog/ [quoted text, click to view] "Myron Marston" <guitar_melosh@hotmail.com> wrote in message
news:1122509025.115984.119030@g14g2000cwa.googlegroups.com... > When an unhandled exception occurs in my low-level framework, I want to > display a message to the user using MessageBox.Show(). However, > depending on where the exception is caught, this sometimes locks my > application. Specifically, I tried wrapping my Sub Main in try-catch > blocks, and it blocked. I can understand how this would occur, since > at that point it is no longer in the message pump and will not process > messages. I tried to fix this by moving the try-catch up the call > stack a level and put it in ApplicationEx.Pump(), like so: > > private static bool Pump() > { > ArrayList MyMessageFilters = new ArrayList(); > // there are, so get the top one > if (GetMessage(out msg, IntPtr.Zero, 0, 0)) > { > try > { > // the usual code goes here > } > catch (Exception ex) > { > MessageBox.Show("Exception: " & ex.Message); > } > } > else > { > return false; > } > > return true; > } > > However, my application is still blocking when the catch is reached and > MessageBox.Show is displayed. It seems like the message pump should > continue, but it's not. Why not? Is there a best practice for where > to put the outermost exception handler in a CF app? >
Unfortunately, my app is spread across 80+ source files (both VB.Net
and C#) in multiple assemblies, so it's a bit difficult to reduce it down to a postable example. I've looked into it some more, however, and discovered the following... - When Message.Box.Show is called from the catch within ApplicationEx.Pump, it returns immediately. This is not the usual behavior of MessageBox.Show. - The next time GetMessage is called, it returns false, causing the message pump loop to exit, and the thread to exit. - My background thread closes on Form.Close(), but since this never is reached it continues running, and my application freezes. - According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40/html/cerefgetmessage.asp, GetMessage returns false when a WM_QUIT message is received. So, it appears that when the exception is thrown, WM_QUIT gets sent. Why is this? Can I prevent that from happening? Why would MessageBox.Show return immediately in this case? And more generally, given that the CF doesn't allow for global exception handling, what are the best practices for exception handling?
[quoted text, click to view]
> given that the CF doesn't allow for global exception handling, what are Try catch all the potential throwable methods I am afraid. Or use CF 2.0 if > the best practices for exception handling? that is acceptable given the November release date. Cheers Daniel -- http://www.danielmoth.com/Blog/ [quoted text, click to view] "Myron Marston" <guitar_melosh@hotmail.com> wrote in message
news:1122581247.633448.89800@g43g2000cwa.googlegroups.com... > Unfortunately, my app is spread across 80+ source files (both VB.Net > and C#) in multiple assemblies, so it's a bit difficult to reduce it > down to a postable example. I've looked into it some more, however, > and discovered the following... > > - When Message.Box.Show is called from the catch within > ApplicationEx.Pump, it returns immediately. This is not the usual > behavior of MessageBox.Show. > - The next time GetMessage is called, it returns false, causing the > message pump loop to exit, and the thread to exit. > - My background thread closes on Form.Close(), but since this never is > reached it continues running, and my application freezes. > - According to > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40/html/cerefgetmessage.asp, > GetMessage returns false when a WM_QUIT message is received. > > So, it appears that when the exception is thrown, WM_QUIT gets sent. > Why is this? Can I prevent that from happening? Why would > MessageBox.Show return immediately in this case? And more generally, > given that the CF doesn't allow for global exception handling, what are > the best practices for exception handling? >
[quoted text, click to view]
> Try catch all the potential throwable methods I am afraid. Or use CF 2.0 if > that is acceptable given the November release date. We're releasing this by the end of August, so CF 2.0 is not an option in this case. I did something like what you suggest--I put try-catch liberally throughout my code. Rather than doing it around all throwable methods, I did it around all event handlers (and around the equivalent overrides in my custom controls) as well as around any callbacks (such as callbacks passed to an asynchrounous web service call). This should theoretically always catch the exception before it passes to unmanaged code. So far it seems to work well. Thanks for the help. [quoted text, click to view] Daniel Moth wrote:
> > given that the CF doesn't allow for global exception handling, what are > > the best practices for exception handling? > Try catch all the potential throwable methods I am afraid. Or use CF 2.0 if > that is acceptable given the November release date. > > Cheers > Daniel > -- > http://www.danielmoth.com/Blog/ > > > "Myron Marston" <guitar_melosh@hotmail.com> wrote in message > news:1122581247.633448.89800@g43g2000cwa.googlegroups.com... > > Unfortunately, my app is spread across 80+ source files (both VB.Net > > and C#) in multiple assemblies, so it's a bit difficult to reduce it > > down to a postable example. I've looked into it some more, however, > > and discovered the following... > > > > - When Message.Box.Show is called from the catch within > > ApplicationEx.Pump, it returns immediately. This is not the usual > > behavior of MessageBox.Show. > > - The next time GetMessage is called, it returns false, causing the > > message pump loop to exit, and the thread to exit. > > - My background thread closes on Form.Close(), but since this never is > > reached it continues running, and my application freezes. > > - According to > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40/html/cerefgetmessage.asp, > > GetMessage returns false when a WM_QUIT message is received. > > > > So, it appears that when the exception is thrown, WM_QUIT gets sent. > > Why is this? Can I prevent that from happening? Why would > > MessageBox.Show return immediately in this case? And more generally, > > given that the CF doesn't allow for global exception handling, what are > > the best practices for exception handling? > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |