Vue d’ensemble de la gestion d’applications

Toutes les applications tendent à partager un jeu de fonctionnalités commun qui s’applique à l’implémentation et à la gestion. Cette rubrique fournit une vue d’ensemble des fonctionnalités de la classe pour la création et la Application gestion d’applications.

Classe d’application

Dans WPF, les fonctionnalités courantes dans l’étendue de l’application sont encapsulées dans la Application classe. La Application classe inclut les fonctionnalités suivantes :

• Suivi et interaction avec la durée de vie d’une application.

• Récupération et traitement des paramètres de ligne de commande.

• Détection et traitement des exceptions non gérées.

• Partage des propriétés de portée application et des ressources .

• Gestion des fenêtres dans des applications autonomes.

• Suivi et gestion de la navigation.

Comment effectuer des tâches courantes à l’aide de la classe Application

Si vous n’êtes pas intéressé par tous les détails de la Application classe, le tableau suivant répertorie certaines des tâches courantes et Application comment les accomplir. En affichant l’API et les rubriques connexes, vous pouvez obtenir davantage d’informations et des exemples de code.

Définition d’application

Pour utiliser les fonctionnalités de la Application classe, vous devez implémenter une définition d’application. Une définition d’application WPF est une classe qui dérive et Application est configurée avec un paramètre MSBuild spécial.

Implémentation d’une définition d’application

Une définition d’application WPF classique est implémentée à l’aide du balisage et du code-behind. Vous pouvez ainsi utiliser le balisage pour définir de façon déclarative les propriétés d’une application et les ressources ainsi que pour inscrire des événements, tout en gérant les événements et en implémentant le comportement spécifique à l’application dans un fichier code-behind.

L’exemple suivant montre comment implémenter une définition d’application à l’aide de balisage et de code-behind :

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

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

Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
    End Class
End Namespace

Pour permettre l’interopérabilité d’un fichier de balisage et d’un fichier code-behind, les conditions suivantes doivent être satisfaites :

• Dans le balisage, l’élément Application doit inclure l’attribut x:Class. Lorsque l’application est générée, l’existence du fichier de x:Class balisage entraîne la création d’une partial classe qui dérive Application et dont le nom est spécifié par l’attribut x:Class . Cela nécessite l’ajout d’une déclaration d’espace de noms XML pour le schéma XAML (xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml").

• Dans code-behind, la classe doit être une partial classe portant le même nom que celui spécifié par l’attribut dans le x:Class balisage et doit dériver de Application. Cela permet au fichier code-behind d’être associé à la partial classe générée pour le fichier de balisage lorsque l’application est générée (voir Génération d’une application WPF).

Ce code est le minimum requis pour implémenter une définition d’application. Toutefois, une configuration MSBuild supplémentaire doit être effectuée dans la définition de l’application avant de générer et d’exécuter l’application.

Configuration de la définition d’application pour MSBuild

Les applications autonomes et les applications de navigateur XAML (XBAPs) nécessitent l’implémentation d’un certain niveau d’infrastructure avant de pouvoir s’exécuter. La partie la plus importante de cette infrastructure est le point d’entrée. Quand une application est lancée par un utilisateur, le système d’exploitation appelle le point d’entrée, qui est une fonction connue pour démarrer les applications.

En règle générale, les développeurs ont toujours dû écrire eux-mêmes une partie ou l’intégralité de ce code, selon la technologie employée. Toutefois, WPF génère ce code pour vous lorsque le fichier de balisage de votre définition d’application est configuré en tant qu’élément MSBuild ApplicationDefinition , comme indiqué dans le fichier projet MSBuild suivant :

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

Étant donné que le fichier code-behind contient du code, il est marqué comme élément MSBuild Compile , comme c’est normal.

L’application de ces configurations MSBuild aux fichiers de balisage et de code-behind d’une définition d’application entraîne la génération de code msBuild comme suit :

using System;
using System.Windows;

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()
        {
            // Initialization code goes here.
        }
    }
}

Imports System.Windows

Namespace SDKSample
    Public Class App
        Inherits Application
        Public Sub New()
        End Sub
        <STAThread>
        Public Shared Sub Main()
            ' Create new instance of application subclass
            Dim app As 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()
        End Sub

        Public Sub InitializeComponent()
            ' Initialization code goes here.	
        End Sub
    End Class
End Namespace

Le code résultant ajoute à votre définition d’application le code d’infrastructure supplémentaire, qui inclut la méthode de point d’entrée Main. L’attribut STAThreadAttribute est appliqué à la Main méthode pour indiquer que le thread d’interface utilisateur principal de l’application WPF est un thread STA, requis pour les applications WPF. Lorsqu’elle est appelée, Main crée une nouvelle instance d’avant App d’appeler la InitializeComponent méthode pour inscrire les événements et définir les propriétés implémentées dans le balisage. Étant donné que InitializeComponent vous êtes généré pour vous, vous n’avez pas besoin d’appeler InitializeComponent explicitement à partir d’une définition d’application comme vous le faites pour Page et Window les implémentations. Enfin, la Run méthode est appelée pour démarrer l’application.

Obtention de l’application actuelle

Étant donné que les fonctionnalités de la Application classe sont partagées entre une application, il ne peut y avoir qu’une seule instance de la Application classe par AppDomain. Pour appliquer cela, la Application classe est implémentée en tant que classe singleton (voir Implémentation de Singleton en C#), qui crée une instance unique de lui-même et fournit un accès partagé à celle-ci avec la staticCurrent propriété.

Le code suivant montre comment acquérir une référence à l’objet pour l’objet Application actuel AppDomain.

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

' Get current application
Dim current As Application = App.Current

Current retourne une référence à une instance de la Application classe. Si vous souhaitez obtenir une référence à votre Application classe dérivée, vous devez caster la valeur de la Current propriété, comme illustré dans l’exemple suivant.

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

' Get strongly-typed current application
Dim appCurrent As App = CType(App.Current, App)

Vous pouvez inspecter la valeur d’un Current point quelconque dans la durée de vie d’un Application objet. Toutefois, vous devez être vigilant. Une fois la Application classe instanciée, il existe une période pendant laquelle l’état de l’objet Application est incohérent. Pendant cette période, Application effectue les différentes tâches d’initialisation requises par votre code pour s’exécuter, notamment l’établissement de l’infrastructure d’application, la définition des propriétés et l’inscription d’événements. Si vous essayez d’utiliser l’objet Application pendant cette période, votre code peut avoir des résultats inattendus, en particulier s’il dépend des différentes Application propriétés définies.

Une fois Application son travail d’initialisation terminé, sa durée de vie commence vraiment.

Durée de vie d’une application

La durée de vie d’une application WPF est marquée par plusieurs événements déclenchés par Application le fait de vous informer lorsque votre application a démarré, a été activée et désactivée et a été arrêtée.

Écran de démarrage

À compter du .NET Framework 3.5 SP1, vous pouvez spécifier une image à utiliser dans une fenêtre de démarrage ou un écran de démarrage. La SplashScreen classe facilite l’affichage d’une fenêtre de démarrage pendant le chargement de votre application. La SplashScreen fenêtre est créée et affichée avant Run d’être appelée. Pour plus d’informations, consultez Temps de démarrage d’une application et Ajouter un écran de démarrage dans une application WPF.

Démarrage d’une application

Une fois Run appelée et l’application initialisée, l’application est prête à s’exécuter. Ce moment est signifie lorsque l’événement Startup est déclenché :

using System.Windows;

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

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Application is running
            '</SnippetStartupCODEBEHIND1>
    End Class
End Namespace
'</SnippetStartupCODEBEHIND2>

À ce stade de la durée de vie d’une application, la chose la plus courante consiste à afficher une interface utilisateur.

Affichage d’une interface utilisateur

La plupart des applications Windows autonomes ouvrent un Window moment où elles commencent à s’exécuter. Le Startup gestionnaire d’événements est un emplacement à partir duquel vous pouvez effectuer cette opération, comme illustré par le code suivant.

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

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

Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Open a window
            Dim window As New MainWindow()
            window.Show()
        End Sub
    End Class
End Namespace

Quand un XBAP démarre pour la première fois, il accède probablement à un Page. Cela est illustré dans le code suivant.

<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;
using System.Windows;
using System.Windows.Navigation;

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

Imports System.Windows
Imports System.Windows.Navigation

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            CType(Me.MainWindow, NavigationWindow).Navigate(New Uri("HomePage.xaml", UriKind.Relative))
        End Sub
    End Class
End Namespace

Si vous gérez Startup uniquement pour ouvrir un Window ou accéder à un Page, vous pouvez définir l’attribut dans le balisage à la StartupUri place.

L’exemple suivant montre comment utiliser l’application StartupUri autonome pour ouvrir un Window.

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

L’exemple suivant montre comment utiliser StartupUri à partir d’un XBAP pour accéder à un Page.

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

Ce balisage a le même effet que le code précédent pour ouvrir une fenêtre.

Vous devez gérer l’événement Startup pour ouvrir un Window événement si vous devez l’instancier à l’aide d’un constructeur sans paramètre, ou vous devez définir ses propriétés ou vous abonner à ses événements avant de l’afficher, ou vous devez traiter les arguments de ligne de commande fournis lors du lancement de l’application.

Traitement des arguments de ligne de commande

Dans Windows, les applications autonomes peuvent être lancées à partir d’une invite de commandes ou du bureau. Dans les deux cas, les arguments de ligne de commande peuvent être passés à l’application. L’exemple suivant montre une application qui est lancée avec un seul argument de ligne de commande, « /StartMinimized » :

wpfapplication.exe /StartMinimized

Lors de l’initialisation de l’application, WPF récupère les arguments de ligne de commande du système d’exploitation et les transmet au Startup gestionnaire d’événements via la Args propriété du StartupEventArgs paramètre. Vous pouvez récupérer et stocker les arguments de ligne de commande à l’aide de code similaire au suivant.

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

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();
        }
    }
}

Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Application is running
            ' Process command line args
            Dim startMinimized As Boolean = False
            Dim i As Integer = 0
            Do While i <> e.Args.Length
                If e.Args(i) = "/StartMinimized" Then
                    startMinimized = True
                End If
                i += 1
            Loop

            ' Create main application window, starting minimized if specified
            Dim mainWindow As New MainWindow()
            If startMinimized Then
                mainWindow.WindowState = WindowState.Minimized
            End If
            mainWindow.Show()
        End Sub
    End Class
End Namespace

Le code gère Startup pour vérifier si l’argument de ligne de commande /StartMinimized a été fourni ; dans ce cas, il ouvre la fenêtre principale avec un WindowState de Minimized. Notez que, étant donné que la WindowState propriété doit être définie par programmation, la principale Window doit être ouverte explicitement dans le code.

Les XBAPs ne peuvent pas récupérer et traiter les arguments de ligne de commande, car ils sont lancés à l’aide du déploiement ClickOnce (voir Déploiement d’une application WPF). En revanche, ils peuvent récupérer et traiter des paramètres de chaîne de requête à partir des URL servant à les lancer.

Activation et désactivation d’une application

Windows permet aux utilisateurs de basculer entre les applications. La façon la plus courante consiste à utiliser la combinaison de touches ALT+TAB. Une application ne peut être basculée que si elle a un visible Window qu’un utilisateur peut sélectionner. La fenêtre actuellement sélectionnée Window est la fenêtre active (également appelée fenêtre de premier plan) et reçoit l’entrée Window de l’utilisateur. L’application contenant la fenêtre active est l’application active (ou application de premier plan). Une application devient l’application active dans les circonstances suivantes :

• Il est lancé et montre un Window.

• Un utilisateur passe d’une autre application en sélectionnant une Window application dans l’application.

Vous pouvez détecter quand une application devient active en gérant l’événement Application.Activated .

De même, une application peut devenir inactive dans les circonstances suivantes :

• Un utilisateur bascule vers une autre application à partir de l’application active.

• L’application s’arrête.

Vous pouvez détecter quand une application devient inactive en gérant l’événement Application.Deactivated .

Le code suivant montre comment gérer les événements et Deactivated les Activated gérer pour déterminer si une application est active.

<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;
using System.Windows;

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;
        }
    }
}

Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private isApplicationActive As Boolean

        Private Sub App_Activated(ByVal sender As Object, ByVal e As EventArgs)
            ' Application activated
            Me.isApplicationActive = True
        End Sub

        Private Sub App_Deactivated(ByVal sender As Object, ByVal e As EventArgs)
            ' Application deactivated
            Me.isApplicationActive = False
        End Sub
    End Class
End Namespace

Un Window peut également être activé et désactivé. Pour plus d'informations, consultez Window.Activated et Window.Deactivated.

Arrêt d’une application

La durée de vie d’une application s’achève quand elle est arrêtée, ce qui peut se produire pour les raisons suivantes :

• Un utilisateur ferme tous les Window.

• Un utilisateur ferme le principal Window.

• Un utilisateur met fin à la session Windows en désactivant ou en arrêtant.

• Une condition spécifique à l’application a été remplie.

Pour vous aider à gérer l’arrêt de l’application, Application fournit la méthode, la Shutdown ShutdownMode propriété et les SessionEnding Exit événements.

Mode d’arrêt

La plupart des applications s’arrêtent à la fermeture de toutes les fenêtres ou de la fenêtre principale. Toutefois, d’autres conditions spécifiques à l’application peuvent parfois déterminer l’arrêt d’une application. Vous pouvez spécifier les conditions dans lesquelles votre application s’arrête en définissant ShutdownMode l’une des valeurs d’énumération suivantes ShutdownMode :

• OnLastWindowClose

• OnMainWindowClose

• OnExplicitShutdown

La valeur ShutdownMode par défaut est OnLastWindowClose, ce qui signifie qu’une application s’arrête automatiquement lorsque la dernière fenêtre de l’application est fermée par l’utilisateur. Toutefois, si votre application doit être arrêtée lorsque la fenêtre principale est fermée, WPF le fait automatiquement si vous définissez ShutdownMode OnMainWindowClosesur . Cela est illustré par l'exemple suivant.

<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" />

Lorsque vous avez des conditions d’arrêt spécifiques à l’application, vous avez la valeur ShutdownMode OnExplicitShutdown. Dans ce cas, il est de votre responsabilité d’arrêter une application en appelant explicitement la Shutdown méthode ; sinon, votre application continue à s’exécuter même si toutes les fenêtres sont fermées. Notez qu’elle Shutdown est appelée implicitement lorsque l’une ou OnMainWindowClosel’autre ShutdownMode OnLastWindowClose est .

Fin de session

Les conditions d’arrêt décrites par la ShutdownMode propriété sont spécifiques à une application. Dans certains cas, pourtant, une application peut s’arrêter à la suite d’une condition externe. La condition externe la plus courante se produit lorsqu’un utilisateur met fin à la session Windows en procédant comme suit :

• Déconnexion

• Arrêt

• Redémarrage

• Mise en veille prolongée

Pour détecter la fin d’une session Windows, vous pouvez gérer l’événement SessionEnding , comme illustré dans l’exemple suivant.

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

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;
            }
        }
    }
}

Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_SessionEnding(ByVal sender As Object, ByVal e As SessionEndingCancelEventArgs)
            ' Ask the user if they want to allow the session to end
            Dim msg As String = String.Format("{0}. End session?", e.ReasonSessionEnding)
            Dim result As MessageBoxResult = MessageBox.Show(msg, "Session Ending", MessageBoxButton.YesNo)

            ' End session, if specified
            If result = MessageBoxResult.No Then
                e.Cancel = True
            End If
        End Sub
    End Class
End Namespace

Dans cet exemple, le code inspecte la ReasonSessionEnding propriété pour déterminer la fin de la session Windows. Il utilise cette valeur pour afficher un message de confirmation à l’attention de l’utilisateur. Si l’utilisateur ne souhaite pas que la session se termine, le code définit Cancel pour true empêcher la fin de la session Windows.

Exit

Quand une application s’arrête, il peut s’avérer nécessaire d’effectuer quelque traitement final, par exemple rendre persistant l’état de l’application. Pour ces situations, vous pouvez gérer l’événement Exit , comme le fait le App_Exit gestionnaire d’événements dans l’exemple suivant. Il est défini en tant que gestionnaire d’événements dans le fichier App.xaml . Son implémentation est mise en surbrillance dans les fichiers App.xaml.cs et Application.xaml.vb .

<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.Resources>
        <SolidColorBrush x:Key="ApplicationScopeResource" Color="White"></SolidColorBrush>
    </Application.Resources>
</Application>

using System.Windows;
using System.IO;
using System.IO.IsolatedStorage;

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

        public App()
        {
            // Initialize application-scope property
            this.Properties["NumberOfAppSessions"] = 0;
        }

        private void App_Startup(object sender, StartupEventArgs e)
        {
            // Restore application-scope property from isolated storage
            IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForDomain();
            try
            {
                using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(filename, FileMode.Open, storage))
                using (StreamReader reader = new StreamReader(stream))
                {
                    // Restore each application-scope property individually
                    while (!reader.EndOfStream)
                    {
                        string[] keyValue = reader.ReadLine().Split(new char[] {','});
                        this.Properties[keyValue[0]] = keyValue[1];
                    }
                }
            }
            catch (FileNotFoundException ex)
            {
                // Handle when file is not found in isolated storage:
                // * When the first application session
                // * When file has been deleted
            }
        }

        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]);
                }
            }
        }
    }
}

Imports System.IO
Imports System.IO.IsolatedStorage

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private filename As String = "App.txt"

        Public Sub New()
            ' Initialize application-scope property
            Me.Properties("NumberOfAppSessions") = 0
        End Sub

        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Restore application-scope property from isolated storage
            Dim storage As IsolatedStorageFile = IsolatedStorageFile.GetUserStoreForDomain()
            Try
                Using stream As New IsolatedStorageFileStream(filename, FileMode.Open, storage)
                Using reader As New StreamReader(stream)
                    ' Restore each application-scope property individually
                    Do While Not reader.EndOfStream
                        Dim keyValue() As String = reader.ReadLine().Split(New Char() {","c})
                        Me.Properties(keyValue(0)) = keyValue(1)
                    Loop
                End Using
                End Using
            Catch ex As FileNotFoundException
                ' Handle when file is not found in isolated storage:
                ' * When the first application session
                ' * When file has been deleted
            End Try
        End Sub

        Private Sub App_Exit(ByVal sender As Object, ByVal e As ExitEventArgs)
            ' Persist application-scope property to isolated storage
            Dim storage As IsolatedStorageFile = IsolatedStorageFile.GetUserStoreForDomain()
            Using stream As New IsolatedStorageFileStream(filename, FileMode.Create, storage)
            Using writer As New StreamWriter(stream)
                ' Persist each application-scope property individually
                For Each key As String In Me.Properties.Keys
                    writer.WriteLine("{0},{1}", key, Me.Properties(key))
                Next key
            End Using
            End Using
        End Sub
    End Class
End Namespace

Pour accéder à l’intégralité de l’exemple, consultez Rendre persistantes et restaurer les propriétés de portée application d’une session d’application à l’autre.

Exit peut être géré par les applications autonomes et les XBAPs. Pour les XBAPs, Exit est déclenché dans les circonstances suivantes :

• Un XBAP est éloigné de.

• Dans Internet Explorer, lorsque l’onglet qui héberge le XBAP est fermé.

• Le navigateur est fermé.

Code de sortie

Les applications sont principalement lancées par le système d’exploitation en réponse à une requête de l’utilisateur. Toutefois, une application peut être lancée par une autre application pour effectuer une tâche spécifique. Quand l’application lancée s’arrête, il est possible que l’application de lancement souhaite connaître la condition dans laquelle s’est effectué cet arrêt. Dans ces situations, Windows permet aux applications de retourner un code de sortie d’application lors de l’arrêt. Par défaut, les applications WPF retournent une valeur de code de sortie de 0.

Pour modifier le code de sortie, vous pouvez appeler la Shutdown(Int32) surcharge, qui accepte un argument entier comme code de sortie :

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

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

Vous pouvez détecter la valeur du code de sortie et le modifier en gérant l’événement Exit . Le Exit gestionnaire d’événements est passé, ExitEventArgs qui fournit l’accès au code de sortie avec la ApplicationExitCode propriété. Pour plus d’informations, consultez Exit.

Exceptions non gérées

Il peut parfois arriver qu’une application s’arrête anormalement, par exemple en cas d’exception inattendue. Dans ce cas, il est possible qu’elle n’ait pas le code nécessaire à la détection et au traitement de l’exception. Ce type d’exception est une exception non gérée ; une notification similaire à celle illustrée dans la figure ci-dessous s’affiche avant la fermeture de l’application.

Du point de vue de l’expérience utilisateur, il est préférable pour une application d’éviter ce comportement par défaut en effectuant certaines ou l’ensemble des opérations suivantes :

• Affichage d’informations conviviales.

• Tentative de maintenir une application en cours d’exécution.

• Enregistrement d’informations détaillées sur les exceptions conviviales pour les développeurs dans le journal des événements Windows.

L’implémentation de cette prise en charge dépend de la possibilité de détecter des exceptions non gérées, ce qui correspond à ce que l’événement DispatcherUnhandledException est déclenché.

<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;
using System.Windows.Threading;

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;
        }
    }
}

Imports System.Windows
Imports System.Windows.Threading

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_DispatcherUnhandledException(ByVal sender As Object, ByVal e As DispatcherUnhandledExceptionEventArgs)
            ' Process unhandled exception

            ' Prevent default unhandled exception processing
            e.Handled = True
        End Sub
    End Class
End Namespace

Le DispatcherUnhandledException gestionnaire d’événements est passé à un DispatcherUnhandledExceptionEventArgs paramètre qui contient des informations contextuelles concernant l’exception non gérée, y compris l’exception elle-même (DispatcherUnhandledExceptionEventArgs.Exception). Vous pouvez utiliser ces informations pour déterminer comment gérer l’exception.

Lorsque vous gérez DispatcherUnhandledException, vous devez définir la DispatcherUnhandledExceptionEventArgs.Handled propriété truesur ; sinon, WPF considère toujours l’exception comme non gérée et rétablit le comportement par défaut décrit précédemment. Si une exception non gérée est levée et que l’événement DispatcherUnhandledException n’est pas géré ou si l’événement est géré et Handled est défini falsesur , l’application s’arrête immédiatement. En outre, aucun autre Application événement n’est déclenché. Par conséquent, vous devez gérer DispatcherUnhandledException si votre application a du code qui doit s’exécuter avant l’arrêt de l’application.

Bien qu’une application puisse s’arrêter à la suite d’une exception non gérée, elle s’arrête habituellement en réponse à une requête de l’utilisateur, comme décrit dans la section suivante.

Événements de durée de vie de l'application

Les applications autonomes et les XBAPs n’ont pas exactement les mêmes durées de vie. La figure suivante illustre les principaux événements de la durée de vie d’une application autonome et indique l’ordre dans lequel ils sont déclenchés.

De même, la figure suivante illustre les événements clés dans la durée de vie d’un XBAP et montre la séquence dans laquelle ils sont déclenchés.

Voir aussi

• Application
• Vue d'ensemble des fenêtres WPF
• Vue d’ensemble de la navigation
• Fichiers de ressources, de contenu et de données d’une application WPF
• URI à en-tête pack dans WPF
• Rubriques Comment relatives au modèle d’application
• Développement d'applications