WPF Application Events
You can best see the life cycle of a standard application in the set of events that it
exposes:*
• Startup
• Activated
• Deactivated
• DispatcherUnhandledException
• SessionEnding
• Exit
Startup event
The Application object’s Startup event is fired when the application’s Run method is
called, and it is a useful place to do application-wide initialization, including the
handling of command-line arguments, which are passed in the StartupEventArgs:
void App_Startup(object sender, StartupEventArgs e) {
for (int i = 0; i != e.Args.Length; ++i) {
// do something useful with each e.Args[i]
...
}
}
Activated and Deactivated events
The Activated event is called when one of the application’s top-level windows is activated
(e.g., via a mouse click or Alt-Tab). Deactivated is called when your application is
active and another application’s top-level window is activated. These events are handy
when you want to stop or start some interactive part of your application:
void App_Activated(object sender, EventArgs e) {
ResumeGame( );
}
void App_Deactivated(object sender, EventArgs e) {
PauseGame( );
}
DispatcherUnhandledException event
The application’s dispatcher is an object that routes events to the correct place, including
unhandled exceptions. In the event that you’d like to handle an exception otherwise
unhandled in your application—maybe to give the user a chance to save his current
document and exit—you can handle the DispatcherUnhandledException event:
Application Lifetime | 45
void App_DispatcherUnhandledException(
object sender, DispatcherUnhandledExceptionEventArgs e) {
string err = "Oops: " + e.Exception.Message);
MessageBox.Show(err, "Exception", MessageBoxButton.OK);
// Only useful if you've got some way of guaranteeing that
// your app can continue reliably in the face of an exception
// without leaving this AppDomain in an unreliable state...
//e.Handled = true; // stop exception from bringing down the app
}
The Exception property of the DispatcherUnhandledExceptionEventArgs event argument
is useful to communicate to your users what happened, whereas the Handled
property is useful to stop the exception from actually bringing down the application
(although this is a dangerous thing to do and can easily result in data loss).
SessionEnding event
The SessionEnding event is called when the Windows session itself is ending (e.g., in
the event of a shutdown, logoff, or restart):
void App_SessionEnding(object sender, SessionEndingCancelEventArgs e) {
if (MessageBox.Show(
e.ReasonSessionEnding.ToString( ),
"Session Ending",
MessageBoxButton.OKCancel) == MessageBoxResult.Cancel) {
e.Cancel = true; // stop the session from ending
}
}
The ReasonSessionEnding property of the SessionEndingCancelEventArgs event argument
is one value in the ReasonSessionEnding enumeration:
namespace System.Windows {
public enum ReasonSessionEnding {
Logoff = 0,
Shutdown = 1,
}
}
The Cancel property is useful if you’d like to stop the session from ending, although
this is considered rude, and more progressive versions of Windows (like Vista) may
not let you change its decision to end a session at all.
Exit event
The Exit event is called when the application is actually exiting, whether the last
window has gone away, the Application.Shutdown method is called, or the session is
ending. One of the overloads of the Shutdown method allows the programmer to pass
an integer exit code, which is ultimately exposed by the process for use by your favorite Win32 process examination APIs. By default, this value is zero, but you can
observe or override it in the handlers for this event:
void App_Exit(object sender, ExitEventArgs e) {
e.ApplicationExitCode = 452; // keep 'em guessing...
}
