WPF Application Events

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...

}