Re: REPOST: Suppressing the default "Unexpected Error" dialog OR global error handler - CF 2.0
From: Daniel Moth (dmoth74_at_hotmail.com)
Date: 08/01/04
- Next message: Panayotis: "CFCOM WMP streaming problem"
- Previous message: pnp: "SelectNodes"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 1 Aug 2004 19:40:37 +0100
So I run my tests against the CF 2.0 (VS2005 Beta 1)
1. As before try..catch around main catches the exceptions on the GUI thread
2. As before exceptions on background threads result in the ugly built-in
dialog popping up BUT IN ADDITION after hitting the Quit button on the
dialog, *our* exception catch code also runs(!)
3. Exceptions that occur in the Control.Invoked code do not freeze/lock the
app [I really wish this bug gets fixed for CF 1.0 SP3 too]. Instead the
behaviour is identical to case 2.
So for CF 1.0, unless the bug of case 3 gets fixed, you should not wrap main
in a try..catch
For CF 2.0, one hopes that cases 2 & 3 can be altered to only run our code
and not show the built in dialog (hence make it as case 1).
Ideally though there should be parity with the desktop version in this area
and the AppDomain.UnhandledException event implemented...
Feel free to add you own comments
Cheers
Daniel
"Daniel Moth" <dmoth74@hotmail.com> wrote in message
news:OXyXNU4ZEHA.808@tk2msftngp13.phx.gbl...
> Attached is a zip that proves how relying on try..catch around
> Application.Run is a bad idea... Tested with CF 1.0 SP2 and SP3... Let me
> know if I am missing something...
>
> If global error handling is not in the plans for CF 2.0 then please at
least
> give us a way to suppress the Microsoft dialog in our apps...
>
>
> >>> Original post from 7 Oct 2003 follows
>
> Hi
>
> When an error occurs we get the helpful dialog with the exe name as the
> title and text starting with "Error An unexpected error has occurred in
> <filename.exe>. Select Quit and then restart this program or select
Details
> for more information."
>
> The above is fine for debug builds but we don't want this for release
builds
> out in the field. In fact, the above box keeps my gui thread (e.g.
> Forms.Timers) running and hence prevents our watch dog from resetting the
> unit! In any case, we should be able to either suppress the box completely
> or at least catch any exception in a central place and deal with it
> ourselves (own box or just Exit).
>
> I have experimented with try catching Application.Run and there are 3
> behaviours I have come across:
> 1. If the exception is thrown *directly* in the GUI thread, e.g.
> button_click then the try catch works great; problem solved
> 2. If the exception occurs in a background thread then the try catch is
> ignored and the unwanted dialog pops up
> 3. If the exception occurs in the GUI thread as a result of a
Control.Invoke
> then the app freezes/locks up!
>
> Is there a workaround or at least plans to support some solution
> (Application.ThreadException perhaps?) in a future CF release?
>
> Cheers
> Daniel
>
>
>
>
- Next message: Panayotis: "CFCOM WMP streaming problem"
- Previous message: pnp: "SelectNodes"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
