Hi,
When we write tools and wizard style apps we like to use an exception handling pattern that prevents unhandled exceptions crashing the app with the default .Net message. For a Windows Forms app we put a Try.. Catch ex as Exception in the Main() startup routine, and the catch block calls our own exception handler method which displays a better message and writes to a trace file. To be really sure, we also add handlers for the AppDomain.UnhandledException and Application.ThreadException events. These handlers also call our exception handling method. The ThreadException event is raised when an exception unwinds back to the nearest message pump.
In a standard WinForms app, if an exception that you didn’t anticipate is thrown in a handler such as Button.Click, then the ThreadException event will fire. When our handler has dealt with this, the application will continue.
In an Actipro Wizard winform, an unhandled exception inside a handler like Wizard.SelectionChanging does not cause ThreadException to fire as it unwinds. Instead the original exception seems to be thrown twice. It’s almost like the exception is being squashed by a Try..Catch everything somewhere in the Actipro part of the stack.
One way to work around this is put a Try..Catch in every Actipro handler I implement, but this isn’t very nice. I was wondering what everyone else does about consistent exception handling in their wizards?
We're using Wizard v3.0.0133 for Windows Forms.
Regards
Pete
When we write tools and wizard style apps we like to use an exception handling pattern that prevents unhandled exceptions crashing the app with the default .Net message. For a Windows Forms app we put a Try.. Catch ex as Exception in the Main() startup routine, and the catch block calls our own exception handler method which displays a better message and writes to a trace file. To be really sure, we also add handlers for the AppDomain.UnhandledException and Application.ThreadException events. These handlers also call our exception handling method. The ThreadException event is raised when an exception unwinds back to the nearest message pump.
In a standard WinForms app, if an exception that you didn’t anticipate is thrown in a handler such as Button.Click, then the ThreadException event will fire. When our handler has dealt with this, the application will continue.
In an Actipro Wizard winform, an unhandled exception inside a handler like Wizard.SelectionChanging does not cause ThreadException to fire as it unwinds. Instead the original exception seems to be thrown twice. It’s almost like the exception is being squashed by a Try..Catch everything somewhere in the Actipro part of the stack.
One way to work around this is put a Try..Catch in every Actipro handler I implement, but this isn’t very nice. I was wondering what everyone else does about consistent exception handling in their wizards?
We're using Wizard v3.0.0133 for Windows Forms.
Regards
Pete
