MessageBox.Show Sometimes Locks my application

[Myron Marston]

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?

 

[Daniel Moth]

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

 

[Myron Marston]

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?

 

[Daniel Moth]

(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

 

[Myron Marston]

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?

 

[Daniel Moth]

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

 

[Myron Marston]

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.