How to determine if calling app is window or console

[Dean Slindee]

I have a exception handling class that could be called from either a windows
project app or a console project app. Is there any way for this class to
determine which type of app called it without sending an window/console
parameter from either app?

Thanks,
Dean Slindee

 

[Tom Dacon]

I can't help you with that determination (it may not be easy, if it's even
possible), and the following comments may be way off base. I apologize if
this is so. But I suspect that the reason you're trying to find this out is
so that you can decide whether to display dialogs in the class. If this is
where you're going, I'd like to suggest that you leave the decision about UI
interactions to the code that is using your class, rather than doing it
within your class. Over the years, every time I've written library classes
that displayed dialogs, on the assumption that they were going to be used
exclusively in interactive applications and that the interactive
applications would always want the dialogs to be displayed, I've almost
always later regretted it, and have had to retrofit them with kludges such
as boolean arguments that determine whether or not to display dialogs. So in
general I'd recommend leaving the UI interaction out of the libraries, and
let the application decide what to do with the results of processing.

Tom Dacon
Dacon Software Consulting

 

[Dean Slindee]

Tom,
You're right on the mark with your assumption. I want to display one (and
only one) exception dialog to the user, tellling him what went wrong, and
providing a textbox where the user can enter any helpful comments about what
he was doing just before the exception occurred. In addition, the exception
class would send the exception (and comments) via email to the help desk,
append an image of the foreground window or desktop to the email, while
logging everything to the application's exception table.

I am writing the application(s) where the exception class would be used, not
marketing the code as an "addin". Could you provide a few examples from
your experience where this approach of putting the dialog box in the
exception class became a burden? Perhaps I can better judge....

Thanks for your reply.
Dean Slindee

 

[Jay B. Harlow [MVP - Outlook]]

Dean,
In addition to Tom's comments.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

In your example: for my Windows Console application I would only handle the
AppDomain.UnhandledException event, possible using the Console API to query
the user, and send the results. For a Windows Forms application I would
handle at least the Application.ThreadException and possible the
AppDomain.UnhandledException (based on the info in the above link) using a
Windows Form to query the user and send the results. For a Windows Service I
would not query the user, instead simply logging & sending the info...

Because the event handlers are local to the application they would know what
type of application it is...

In either case I would log the information also, in case physically sending
is not an option.

Hope this helps
Jay