Übersicht über die Anwendungsverwaltung

 

Veröffentlicht: Juni 2016

Alle Anwendungen neigen, eine einheitliche freizugeben, die von der Funktion festgelegt wird, an die Implementierung und Verwaltung von Anwendungen gelten soll. Dieses Thema bietet eine Übersicht über die Funktionen in der Application-Klasse zum Erstellen und Verwalten von Anwendungen bereit.

Entity with relative path '../Token/autoOutline_md.md' can not be found, for source topic '{"project_id":"3fedad16-eaf1-41a6-8f96-0c1949c68f32","entity_id":"32b1c054-5aca-423b-b4b5-ed8dc4dc637d","entity_type":"Article","locale":"de-DE"}'.

In WPFallgemeinen anwendungsspezifischen Funktionen wird in der Application-Klasse gekapselt. Die Application-Klasse umfasst die folgenden Funktionen:

  • Verfolgen und Beeinflussen der Lebensdauer einer Anwendung

  • Abrufen und Verarbeiten von Befehlszeilenparametern

  • Erkennen von und Reagieren auf nicht behandelte Ausnahmen

  • Freigeben anwendungsspezifischer Eigenschaften und Ressourcen

  • Verwalten von Fenstern in eigenständigen Anwendungen

  • Verfolgen und Verwalten der Navigation.

Wenn Sie nicht alle Details der Application-Klasse interessiert sind, werden in der folgenden Tabelle Application für gängige Aufgaben aufgelistet und deren Verwendung. Mit der verwandten APIs und die Themen anzeigen, können Sie weitere Informationen und Beispielcode finden.

AufgabeVorgehensweise
Ruft ein Objekt ab, das die aktuelle Anwendung darstelltVerwenden Sie die Application.Current-Eigenschaft.
Fügen Sie einen Startbildschirm einer Anwendung hinzuWeitere Informationen finden Sie unter Hinzufügen eines Begrüßungsbildschirms zu einer WPF-Anwendung.
Starten einer AnwendungVerwenden Sie die Application.Run-Methode.
Beenden einer AnwendungVerwenden Sie die Shutdown-Methode des Application.Current-Objekts.
Rufen Sie Argumente in der Befehlszeile abBehandeln Sie das Application.Startup-Ereignis, und verwenden Sie die StartupEventArgs.Args-Eigenschaft. Ein Beispiel finden Sie unter Application.Startup-Ereignis.
Abrufen und Festlegen von der Anwendungsexitcode festLegen Sie die ExitEventArgs.ApplicationExitCode-Eigenschaft im Application.Exit-Ereignishandler fest, oder rufen Sie die Shutdown-Methode auf, und übergeben Sie eine ganze Zahl.
Erkennen von und Reagieren auf AusnahmefehlerBehandeln des DispatcherUnhandledException-Ereignisses.
Abrufen und Festlegen von Ressourcen für den Anwendungsbereich festVerwenden Sie die Application.Resources-Eigenschaft.
Verwenden Sie eine Ressource für den Anwendungsbereichen-WörterbuchWeitere Informationen finden Sie unter Verwenden eines Ressourcenwörterbuchs für den Anwendungsbereich.
Abrufen und Festlegen von Eigenschaften für den Anwendungsbereich festVerwenden Sie die Application.Properties-Eigenschaft.
Abrufen und speichern Sie den Zustand einer AnwendungWeitere Informationen finden Sie unter Beibehalten und Wiederherstellen von Eigenschaften für den Anwendungsbereich über mehrere Anwendungssitzungen.
Verwalten von Datendateien ohne Code, darunter Ressourcendateien, Inhaltsdateien sowie Dateien der Ursprungssite.Weitere Informationen finden Sie unter WPF-Anwendungsressource, Inhalts- und Datendateien.
Verwalten von Fenstern in eigenständigen AnwendungenWeitere Informationen finden Sie unter Übersicht über WPF-Fenster.
Verfolgen Sie nach und Verwalten der NavigationWeitere Informationen finden Sie unter Übersicht über die Navigation.

Um die Funktionalität der Application-Klasse zu verwenden, müssen Sie eine Anwendungsdefinition implementieren. Bei einer WPF-Anwendungsdefinition handelt es sich um eine Klasse, die von Application abgeleitet wird und mit einer speziellen Microsoft-Buildmodul (MSBuild)-Einstellung konfiguriert wurde.

Implementieren einer Anwendungsdefinition

Eine typische WPF-Anwendungsdefinition wird sowohl mit Markup als auch mit Code-Behind implementiert. Dies ermöglicht Ihnen die Verwendung von Markup zum deklarativen Festlegen der Eigenschaften und Ressourcen von Anwendungen sowie zum Registrieren von Ereignissen, während im Code-Behind die Ereignisbehandlung erfolgt und anwendungsspezifisches Verhalten implementiert wird.

Im folgenden Beispiel wird gezeigt, wie Sie eine Anwendungsdefinition sowohl mit Markup als auch mit Code-Behind implementieren:

<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  x:Class="SDKSample.App" />

using System.Windows;  // Application

namespace SDKSample
{
    public partial class App : Application { }
}

Damit Markup- und Code-Behind-Datei zusammenarbeiten können, müssen folgende Voraussetzungen erfüllt sein:

  • Im Markup muss das Application-Element das x:Class-Attribut enthalten. Beim Erstellen der Anwendung führt das Vorhandensein von x:Class in der Markupdatei dazu, dass MSBuild eine partial-Klasse erstellt, die aus Application abgeleitet wird und den durch das x:Class-Attribut festgelegten Namen hat. Dies erfordert das Hinzufügen einer XML-Namespacedeklaration für das XAML-Schema (xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml").

  • Im Code-Behind muss die Klasse eine partial-Klasse mit demselben Namen sein, der im Markup durch das x:Class-Attribut angegeben ist, und sie muss von Application abgeleitet werden. Auf diese Weise kann die Code-Behind-Datei mit der partial-Klasse verknüpft werden, die beim Erstellen der Anwendung (siehe Erstellen einer WPF-Anwendung) für die Markupdatei generiert wird.

System_CAPS_ICON_note.jpg Hinweis

Wenn Sie mithilfe von Microsoft Visual Studio ein neues WPF-Anwendungsprojekt oder ein WPF-Browseranwendungsprojekt erstellen, ist standardmäßig eine Anwendungsdefinition enthalten, und die Definition erfolgt sowohl mit Markup als auch mit Code-Behind.

Dieser Code stellt die Mindestanforderung zum Implementieren einer Anwendungsdefinition dar. Bevor die Anwendung erstellt und ausgeführt werden kann, muss in der Anwendungsdefinition jedoch eine zusätzliche MSBuild-Konfiguration vorgenommen werden.

Konfigurieren der Anwendungsdefinition für MSBuild

Eigenständige Anwendungen und XAML-Browseranwendungen (XAML browser applications; XBAPs) erfordern die Implementierung einer bestimmten Infrastrukturebene, bevor sie ausgeführt werden können. Der wichtigste Teil dieser Infrastruktur ist der Einstiegspunkt. Wenn eine Anwendung von einem Benutzer gestartet wird, ruft das Betriebssystem den Einstiegspunkt auf. Diese Funktion ist bekannt für das Starten von Anwendungen.

Bisher mussten Entwickler diesen Code zum Teil oder auch komplett selbst schreiben, je nach Technologie. In WPF wird dieser Code jedoch für Sie generiert, wenn die Markupdatei Ihrer Anwendungsdefinition als ApplicationDefinition-Element von MSBuild konfiguriert ist, wie in der folgenden Projektdatei von MSBuild veranschaulicht:

<Project   
  DefaultTargets="Build"  
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">  
  ...  
  <ApplicationDefinition Include="App.xaml" />  
  <Compile Include="App.xaml.cs" />  
  ...  
</Project>  

Da die Code-Behind-Datei Code enthält, wird sie ganz normal als ein Compile-Element von MSBuild gekennzeichnet.

Werden diese MSBuild-Konfigurationen auf die Markup- und Code-Behind-Dateien einer Anwendungsdefinition angewendet, generiert MSBuild Code, der dem folgenden ähnelt:

using System; // STAThread
using System.Windows; // Application

namespace SDKSample
{
    public class App : Application
    {
        public App() { }
        [STAThread]
        public static void Main()
        {
            // Create new instance of application subclass
            App app = new App();

            // Code to register events and set properties that were
            // defined in XAML in the application definition
            app.InitializeComponent();

            // Start running the application
            app.Run();
        }

        public void InitializeComponent()
        {

        }
    }
}

Durch den resultierenden Code wird die Anwendungsdefinition um zusätzlichen Infrastrukturcode erweitert, darunter die Einstiegspunktmethode Main. Das STAThreadAttribute-Attribut wird auf die Main-Methode angewendet. Damit wird angegeben, dass der Hauptthread der UI für die WPF-Anwendung ein STA-Thread ist, der für WPF-Anwendungen erforderlich ist. Beim Aufrufen erstellt Main eine neue Instanz von App, bevor die InitializeComponent-Methode aufgerufen wird, um die Ereignisse zu registrieren und die im Markup implementierten Eigenschaften festzulegen. Da InitializeComponent automatisch für Sie generiert wird, müssen Sie InitializeComponent nicht explizit aus einer Anwendungsdefinition aufrufen, wie es bei einer Page-Implementierung und Window-Implementierung der Fall ist. Abschließend wird die Run-Methode zum Starten der Anwendung aufgerufen.

Da die Funktionen der Application-Klasse zu einer Anwendung gemeinsam verwendet werden, kann es nur eine Instanz der Application-Klasse pro AppDomaingeben. Um dies zu erzwingen, wird die Application-Klasse als Singletonklasse implementiert (siehe Implementing Singleton in C#). Diese erstellt eine einzelne Instanz von sich selbst und ermöglicht den gemeinsamen Zugriff mit der static Current-Eigenschaft.

Der folgende Code zeigt, wie ein Verweis auf das Application-Objekt für die aktuelle AppDomain abgerufen wird.

            // Get current application
            Application current = App.Current;

Current gibt einen Verweis auf eine Instanz der Application-Klasse zurück. Wenn Sie einen Verweis auf die abgeleitete Application-Klasse benötigen, müssen Sie den Wert der Current-Eigenschaft umwandeln, wie im folgenden Beispiel gezeigt.

            // Get strongly-typed current application
            App app = (App)App.Current;

Sie können den Wert von Current zu jedem Zeitpunkt in der Lebensdauer eines Application-Objekts überprüfen. Gehen Sie dabei vorsichtig vor. Nachdem die Application-Klasse instanziiert wurde, tritt ein Zeitraum auf, in dem der Zustand des Application-Objekts inkonsistent ist. Während dieses Zeitraums führt Application die verschiedenen Initialisierungsaufgaben durch, die zum Ausführen des Codes erforderlich sind. Dazu gehören das Einrichten der Anwendungsinfrastruktur, das Festlegen von Eigenschaften und das Registrieren von Ereignissen. Wenn Sie während dieses Zeitraums versuchen, das Application-Objekt zu verwenden, gibt der Code möglicherweise unerwartete Ergebnisse zurück, insbesondere dann, wenn er von den verschiedenen festgelegten Application-Eigenschaften abhängt.

Wenn Application die Initialisierung abgeschlossen hat, beginnt die eigentliche Lebensdauer.

Die Lebensdauer einer WPF-Anwendung ist durch verschiedene Ereignisse gekennzeichnet, die von Application ausgelöst werden. Sie informieren darüber, wann die Anwendung gestartet, aktiviert und deaktiviert sowie heruntergefahren wurde.

Entity with relative path '../Token/autoOutline_md.md' can not be found, for source topic '{"project_id":"3fedad16-eaf1-41a6-8f96-0c1949c68f32","entity_id":"32b1c054-5aca-423b-b4b5-ed8dc4dc637d","entity_type":"Article","locale":"de-DE"}'.

Begrüßungsbildschirm

Wenn Sie in .NET Framework 3.5 SP1 starten, können Sie ein Bild angeben, das in einem Startfenster oder im Begrüßungsbildschirm verwendet werden soll. Mit der SplashScreen-Klasse ist es einfach, ein Startfenster anzuzeigen, während die Anwendung geladen wird. Das Fenster SplashScreen wird erstellt und angezeigt, bevor Run aufgerufen wird. Weitere Informationen finden Sie unter Startzeit der Anwendung und unter Hinzufügen eines Begrüßungsbildschirms zu einer WPF-Anwendung.

Starten einer Anwendung

Nach dem Aufrufen von Run und dem Initialisieren der Anwendung kann sie ausgeführt werden. Dieser Zeitpunkt wird durch Auslösen des Startup-Ereignisses angezeigt:

using System.Windows; // Application, StartupEventArgs, WindowState

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running

        }
    }
}

Wenn dieser Zeitpunkt in der Lebensdauer einer Anwendung gekommen ist, wird in der Regel eine UI angezeigt.

Anzeigen einer Benutzeroberfläche

In den meisten eigenständigen Windows-Anwendungen wird Window geöffnet, wenn ihre Ausführung beginnt. Wie im folgenden Code veranschaulicht, stellt der Startup-Ereignishandler einen geeigneten Ausgangspunkt dafür dar.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App" 
  Startup="App_Startup" />

using System.Windows; // Application, StartupEventArgs

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Open a window
            MainWindow window = new MainWindow();
            window.Show();
        }
    }
}

System_CAPS_ICON_note.jpg Hinweis

Das erste Window, das in einer eigenständigen Anwendung instanziiert werden soll, wird standardmäßig zum Hauptanwendungsfenster. Auf dieses Window-Objekt wird von der Application.MainWindow-Eigenschaft verwiesen. Der Wert der MainWindow-Eigenschaft kann programmgesteuert geändert werden, wenn ein anderes Fenster als das zuerst instanziierte Window das Hauptfenster sein soll.

Wenn zuerst eine XBAP gestartet wird, navigiert diese wahrscheinlich zu einer Page. Dies wird im folgenden Code veranschaulicht.

<Application 
  x:Class="SDKSample.App"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  Startup="App_Startup" />

using System; // Uri, UriKind, EventArgs, Console
using System.Windows; // Application, StartupEventArgs
using System.Windows.Navigation; // NavigationWindow

namespace SDKSample
{
    public partial class App : Application
    {        
        void App_Startup(object sender, StartupEventArgs e)
        {
            ((NavigationWindow)this.MainWindow).Navigate(new Uri("HomePage.xaml", UriKind.Relative));
        }
    }
}

Wenn Sie Startup so behandeln, dass nur ein Window geöffnet oder zu einer Page navigiert wird, können Sie stattdessen das StartupUri-Attribut im Markup festlegen.

Im folgenden Beispiel wird gezeigt, wie Sie die StartupUri einer eigenständigen Anwendung verwenden, um ein Window zu öffnen.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="MainWindow.xaml" />

Im folgenden Beispiel wird gezeigt, wie Sie unter Verwendung von StartupUri von einer XBAP zu einer Page navigieren können.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="HomePage.xaml" />

Dieses Markup hat denselben Effekt wie der vorherige Code zum Öffnen eines Fensters.

System_CAPS_ICON_note.jpg Hinweis

Weitere Informationen zur Navigation finden Sie unter Übersicht über die Navigation.

Sie müssen das Startup-Ereignis behandeln, um ein Window zu öffnen, wenn Sie es mithilfe eines nicht standardmäßigen Konstruktors instanziieren müssen. Oder Sie müssen die Eigenschaften festlegen bzw. Ereignisse abonnieren, bevor Sie das Fenster anzeigen. Sie können aber auch alle Befehlszeilenargumente verarbeiten, die beim Starten der Anwendung bereitgestellt wurden.

Verarbeiten von Befehlszeilenargumenten

In Windows können eigenständige Anwendungen über eine Eingabeaufforderung oder auf dem Desktop gestartet werden. In beiden Fällen können Befehlszeilenargumente an die Anwendung übergeben werden. Im folgenden Beispiel sehen Sie eine Anwendung, die mit nur einem Befehlszeilenargument ("/StartMinimized") gestartet wird:

wpfapplication.exe /StartMinimized

Während der Anwendungsinitialisierung ruft WPF die Befehlszeilenargumente vom Betriebssystem ab und übergibt sie über die Args-Eigenschaft des StartupEventArgs-Parameters an den Startup-Ereignishandler. Mit Code wie dem folgenden können Sie Befehlszeilenargumente abrufen und speichern.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  Startup="App_Startup" />

using System.Windows; // Application, StartupEventArgs, WindowState

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running
            // Process command line args
            bool startMinimized = false;
            for (int i = 0; i != e.Args.Length; ++i)
            {
                if (e.Args[i] == "/StartMinimized")
                {
                    startMinimized = true;
                }
            }

            // Create main application window, starting minimized if specified
            MainWindow mainWindow = new MainWindow();
            if (startMinimized)
            {
                mainWindow.WindowState = WindowState.Minimized;
            }
            mainWindow.Show();
        }
    }
}

Der Code behandelt Startup, um zu überprüfen, ob das /StartMinimized-Befehlszeilenargument angegeben wurde. Ist das der Fall, wird das Hauptfenster mit der WindowState-Eigenschaft Minimized geöffnet. Da die WindowState-Eigenschaft programmgesteuert festgelegt sein muss, ist es erforderlich, das Haupt-Window explizit im Code zu öffnen.

XBAPs können keine Befehlszeilenargumente abrufen und verarbeiten, da sie mit ClickOnce-Bereitstellung gestartet werden (siehe Bereitstellen von WPF-Anwendungen). Von den zum Starten verwendeten URLs können jedoch Abfragezeichenfolgenparameter abgerufen und verarbeitet werden.

Aktivieren und Deaktivieren von Anwendungen

Windows ermöglicht es Benutzern, zwischen Anwendungen zu wechseln. Meistens wird dazu die Tastenkombination ALT+TAB verwendet. Es kann nur dann zu einer Anwendung gewechselt werden, wenn sie über ein sichtbares Window verfügt, das ein Benutzer auswählen kann. Das derzeit ausgewählte Window ist das aktive Fenster (oder Vordergrundfenster) und das Window, das Benutzereingaben empfängt. Die Anwendung mit dem aktiven Fenster ist die aktive Anwendung (oder Vordergrundanwendung). Eine Anwendung wird unter folgenden Umständen zur aktiven Anwendung:

  • Sie wird gestartet und zeigt ein Window an.

  • Ein Benutzer wechselt von einer anderen Anwendung, indem er in der Anwendung ein Window auswählt.

Sie können erkennen, wann eine Anwendung aktiv wird, indem Sie das Application.Activated-Ereignis behandeln.

Auf ähnliche Weise kann eine Anwendung unter folgenden Umständen inaktiv werden:

  • Ein Benutzer wechselt von der aktuellen zu einer anderen Anwendung.

  • Wenn die Anwendung heruntergefahren wird.

Sie können erkennen, wann eine Anwendung inaktiv wird, indem Sie das Application.Deactivated-Ereignis behandeln.

Der folgende Code veranschaulicht, wie Sie das Activated-Ereignis und das Deactivated-Ereignis behandeln, um zu ermitteln, ob eine Anwendung aktiv ist.

<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  Activated="App_Activated" 
  Deactivated="App_Deactivated" />

using System; // EventArgs
using System.Windows; // Application

namespace SDKSample
{
    public partial class App : Application
    {
        bool isApplicationActive;

        void App_Activated(object sender, EventArgs e)
        {
            // Application activated
            this.isApplicationActive = true;
        }

        void App_Deactivated(object sender, EventArgs e)
        {
            // Application deactivated
            this.isApplicationActive = false;
        }
    }
}

Ein Window kann auch aktiviert und deaktiviert werden. Weitere Informationen finden Sie unter Window.Activated und Window.Deactivated.

System_CAPS_ICON_note.jpg Hinweis

Weder Application.Activated noch Application.Deactivated werden für XBAPs ausgelöst.

Herunterfahren einer Anwendung

Die Lebensdauer einer Anwendung endet mit dem Herunterfahren, das aus folgenden Gründen erfolgen kann:

  • Ein Benutzer schließt die einzelnen Window.

  • Ein Benutzer schließt das Haupt-Window.

  • Der Benutzer beendet die Windows-Sitzung, indem er sich abmeldet oder die Anwendung herunterfährt.

  • Eine anwendungsspezifische Bedingung wurde erfüllt.

Um Sie bei der Verwaltung des Herunterfahrens von Anwendungen zu unterstützen, stellt Application die Shutdown-Methode, die ShutdownMode-Eigenschaft und das SessionEnding-Ereignis sowie das Exit-Ereignis bereit.

System_CAPS_ICON_note.jpg Hinweis

Shutdown kann nur von Anwendungen aufgerufen werden, die über UIPermission verfügen. Eigenständige WPF-Anwendungen verfügen immer über diese Berechtigung. Dies ist bei XBAPs, die im teilweise vertrauenswürdigen Sicherheitsbereich (Sandbox) der Internetzone ausgeführt werden, nicht der Fall.

Modus für das Herunterfahren

Anwendungen werden in der Regel entweder heruntergefahren, wenn alle Fenster geschlossen werden, oder wenn das Hauptfenster geschlossen wird. Manchmal kann jedoch auch durch andere anwendungsspezifische Bedingungen bestimmt werden, wann eine Anwendung heruntergefahren wird. Sie können die Bedingungen, unter denen eine Anwendung heruntergefahren werden soll, dadurch angeben, dass Sie ShutdownMode mit einem der folgenden ShutdownMode-Enumerationswerte festlegen:

Der Standardwert von ShutdownMode ist OnLastWindowClose, was bedeutet, dass eine Anwendung automatisch heruntergefahren wird, sobald das letzte Fenster in der Anwendung vom Benutzer geschlossen wird. Ein Herunterfahren der Anwendung beim Schließen des Hauptfensters wird von WPF automatisch ausgeführt, wenn Sie ShutdownMode auf OnMainWindowClose festlegen. Dies wird im folgenden Beispiel gezeigt.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    ShutdownMode="OnMainWindowClose" />

Liegen anwendungsspezifische Bedingungen zum Herunterfahren vor, legen Sie ShutdownMode auf OnExplicitShutdown fest. In diesem Fall müssen Sie sicherstellen, dass Sie eine Anwendung herunterfahren, indem Sie explizit die Shutdown-Methode aufrufen. Andernfalls wird die Anwendung weiterhin ausgeführt, auch wenn alle Fenster geschlossen sind. Beachten Sie, dass Shutdown implizit aufgerufen wird, wenn ShutdownMode entweder OnLastWindowClose oder OnMainWindowClose ist.

System_CAPS_ICON_note.jpg Hinweis

ShutdownMode kann von einer XBAP festgelegt werden, wird aber ignoriert. Eine XBAP wird immer heruntergefahren, wenn in einem Browser von ihr weg navigiert wird oder wenn der Browser, der die XBAP hostet, geschlossen wird. Weitere Informationen finden Sie unter Übersicht über die Navigation.

Beenden einer Sitzung

Die durch die ShutdownMode-Eigenschaft beschriebenen Bedingungen zum Herunterfahren sind spezifisch für eine Anwendung. In einigen Fällen kann eine Anwendung aber auch als Ergebnis einer externen Bedingung heruntergefahren werden. Die gängigste externe Bedingung tritt auf, wenn ein Benutzer die Windows-Sitzung durch die folgenden Aktionen beendet:

  • Abmelden

  • Herunterfahren

  • Neustarten

  • Wechseln in den Ruhezustand

Um zu erkennen, wann eine Windows-Sitzung endet, können Sie das SessionEnding-Ereignis behandeln, wie in folgendem Beispiel gezeigt.

<Application 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml"
    SessionEnding="App_SessionEnding" />

using System.Windows; // Application, SessionEndingCancelEventArgs, MessageBox, MessageBoxResult, MessageBoxButton

namespace SDKSample
{
    public partial class App : Application
    {
        void App_SessionEnding(object sender, SessionEndingCancelEventArgs e)
        {
            // Ask the user if they want to allow the session to end
            string msg = string.Format("{0}. End session?", e.ReasonSessionEnding);
            MessageBoxResult result = MessageBox.Show(msg, "Session Ending", MessageBoxButton.YesNo);

            // End session, if specified
            if (result == MessageBoxResult.No)
            {
                e.Cancel = true;
            }
        }
    }
}

In diesem Beispiel überprüft der Code die ReasonSessionEnding-Eigenschaft, um festzustellen, wie die Windows-Sitzung beendet wird. Dieser Wert wird verwendet, um dem Benutzer eine Bestätigungsmeldung anzuzeigen. Wenn der Benutzer das Beenden der Sitzung verhindern möchte, wird Cancel durch den Code auf true festgelegt. Dann wird die Windows-Sitzung nicht beendet.

System_CAPS_ICON_note.jpg Hinweis

SessionEnding wird für XBAPs nicht ausgelöst.

Exit

Beim Herunterfahren einer Anwendung werden evtl. abschließende Verarbeitungsaufgaben ausgeführt, z. B. Beibehalten des Anwendungszustands. In diesen Situationen können Sie das Exit-Ereignis behandeln.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml" 
    Startup="App_Startup" 
    Exit="App_Exit">

</Application>

using System.Windows; // Application, StartupEventArgs
using System.IO; // StreamReader, FileMode
using System.IO.IsolatedStorage; // IsolatedStorageFile, IsolatedStorageFileStream

namespace SDKSample
{
    public partial class App : Application
    {
        string filename = "App.txt";


        private void App_Exit(object sender, ExitEventArgs e)
        {
            // Persist application-scope property to isolated storage
            IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForDomain();
            using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(filename, FileMode.Create, storage))
            using (StreamWriter writer = new StreamWriter(stream))
            {
                // Persist each application-scope property individually
                foreach (string key in this.Properties.Keys)
                {
                    writer.WriteLine("{0},{1}", key, this.Properties[key]);
                }
            }
        }
    }
}

Das vollständige Beispiel finden Sie unter Beibehalten und Wiederherstellen von Eigenschaften für den Anwendungsbereich über mehrere Anwendungssitzungen.

Exit kann sowohl von eigenständigen Anwendungen als auch von XBAPs behandelt werden. Bei XBAPs wird Exit unter den folgenden Umständen ausgelöst:

  • Es wird von einer XBAP weg navigiert.

  • In Internet Explorer 7, wenn die Registerkarte geschlossen wird, die die XBAP hostet.

  • Wenn der Browser geschlossen wird.

Exitcode

Anwendungen werden meistens durch das Betriebssystem als Reaktion auf eine Benutzeranforderung gestartet. Eine Anwendung kann aber auch von einer anderen Anwendung gestartet werden, um eine bestimmte Aufgabe zu übernehmen. Wenn die gestartete Anwendung heruntergefahren wird, muss die startende Anwendung möglicherweise über die Bedingung informiert werden, unter der die gestartete Anwendung heruntergefahren wurde. In diesen Situationen ermöglicht Windows es Anwendungen, beim Herunterfahren einen Anwendungsexitcode zurückzugeben. Standardmäßig geben WPF-Anwendungen den Exitcodewert 0 (null) zurück.

System_CAPS_ICON_note.jpg Hinweis

Wenn Sie aus Visual Studio debuggen, wird der Anwendungsexitcode beim Herunterfahren im Ausgabefenster angezeigt. Die entsprechende Meldung sieht ungefähr folgendermaßen aus:

The program '[5340] AWPFApp.vshost.exe: Managed' has exited with code 0 (0x0).

Sie öffnen das Ausgabefenster, indem Sie im Menü Ansicht auf Ausgabe klicken.

Zum Ändern des Exitcodes können Sie die Shutdown(Int32)-Überladung aufrufen, die ein Ganzzahlargument als Exitcode akzeptiert:

            // Shutdown and return a non-default exit code
            Application.Current.Shutdown(-1);

Sie können den Wert des Exitcodes ermitteln und ändern, indem Sie das Exit-Ereignis behandeln. Der Exit-Ereignishandler wird an ExitEventArgs übergeben. Dadurch wird der Zugriff auf den Exitcode mit der ApplicationExitCode-Eigenschaft ermöglicht. Weitere Informationen finden Sie unter Exit.

System_CAPS_ICON_note.jpg Hinweis

Sie können den Exitcode sowohl in eigenständigen Anwendungen als auch in XBAPs festlegen. Der Exitcodewert wird für XBAPs allerdings ignoriert.

Nicht behandelte Ausnahmen

Es kommt vor, dass eine Anwendung unter nicht ordnungsgemäßen Bedingungen heruntergefahren wird, z. B. wenn eine unerwartete Ausnahme ausgelöst wird. In diesem Fall verfügt die Anwendung möglicherweise nicht über den Code, der zum Erkennen und Verarbeiten der Ausnahme erforderlich ist. Eine solche Ausnahme wird als nicht behandelte Ausnahme bezeichnet. Vor dem Schließen der Anwendung wird eine Meldung angezeigt, die der folgenden ähnelt.

Benachrichtigung über Ausnahmefehler

Für die Benutzererfahrung ist es vorteilhafter, wenn eine Anwendung dieses Standardverhalten vermeidet. Dazu dienen mehrere oder alle der folgenden Aktionen:

  • Anzeigen von benutzerfreundlichen Informationen

  • Versuchen, eine Anwendung weiterhin auszuführen

  • Aufzeichnen ausführlicher, entwicklerfreundlicher Ausnahmeinformationen im Windows-Ereignisprotokoll

Die Implementierung dieser Unterstützung hängt von der Fähigkeit ab, nicht behandelte Ausnahmen zu erkennen, was der Grund für das Auslösen des DispatcherUnhandledException-Ereignisses ist.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  DispatcherUnhandledException="App_DispatcherUnhandledException" />

using System.Windows; // Application
using System.Windows.Threading; // DispatcherUnhandledExceptionEventArgs

namespace SDKSample
{
    public partial class App : Application
    {
        void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
        {
            // Process unhandled exception

            // Prevent default unhandled exception processing
            e.Handled = true;
        }
    }
}

An den DispatcherUnhandledException-Ereignishandler wird ein DispatcherUnhandledExceptionEventArgs-Parameter übergeben, der Kontextinformationen zur nicht behandelten Ausnahme enthält, darunter die Ausnahme selbst (DispatcherUnhandledExceptionEventArgs.Exception). Sie können anhand dieser Informationen feststellen, wie die Ausnahme behandelt werden soll.

Beim Behandeln von DispatcherUnhandledException sollten Sie die DispatcherUnhandledExceptionEventArgs.Handled-Eigenschaft auf true festlegen. Ansonsten betrachtet WPF die Ausnahme weiterhin als unbehandelt und stellt das zuvor beschriebene Standardverhalten wieder her. Wird eine nicht behandelte Ausnahme ausgelöst und das DispatcherUnhandledException-Ereignis nicht behandelt, oder es wird behandelt, während Handled auf false festgelegt ist, wird die Anwendung sofort heruntergefahren. Darüber hinaus werden keine anderen Application-Ereignisse ausgelöst. Folglich müssen Sie DispatcherUnhandledException behandeln, wenn die Anwendung über Code verfügt, der vor dem Herunterfahren ausgeführt werden muss.

Obwohl eine Anwendung wegen einer nicht behandelten Ausnahme heruntergefahren werden kann, erfolgt das Herunterfahren normalerweise als Reaktion auf eine Benutzeranforderung, wie im nächsten Abschnitt beschrieben.

Lebensdauerereignisse der Anwendung

Eigenständige Anwendungen und XBAPs haben nicht genau dieselbe Lebensdauer. Die folgende Abbildung veranschaulicht die wichtigsten Ereignisse in der Lebensdauer einer eigenständigen Anwendung und die Reihenfolge, in der sie ausgelöst werden.

Eigenständige Anwendung - Anwendungsobjektereignisse

Entsprechend veranschaulicht die folgende Abbildung die wichtigsten Ereignisse in der Lebensdauer einer XBAP und zeigt, in welcher Reihenfolge diese ausgelöst werden.

XBAP - Anwendungsobjektereignisse

Application
Übersicht über WPF-Fenster
Übersicht über die Navigation
WPF-Anwendungsressource, Inhalts- und Datendateien
Paket-URI in WPF
Application Model: How-to Topics
Anwendungsentwicklung

Anzeigen: