Share via

Vue d'ensemble de la gestion d'applications

  • Article

Mise à jour : Juillet 2008

Cette rubrique fournit une vue d'ensemble des services Windows Presentation Foundation (WPF) pour la création et la gestion d'applications. Le noyau d'une application WPF est la classe Application, qui prend en charge divers services essentiels de l'application. Cette rubrique présente les services les plus importants.

Cette rubrique comprend les sections suivantes.

  • Classe d'application
  • Définition d'application.
  • Obtention de l'application actuelle
  • Durée de vie d'une application
  • Autres services d'application
  • Rubriques connexes

Classe d'application

Une application consiste en de nombreux éléments spécifiques à l'application, notamment l'interface utilisateur (UI), la logique métier, la logique d'accès aux données, les contrôles et les données. Ces éléments sont généralement différents d'une application à l'autre. Toutefois, toutes les applications tendent à partager un jeu de fonctionnalités commun, qui facilite leur implémentation et leur gestion. Dans WPF, ces fonctionnalités communes de portée application sont encapsulées dans la classe Application, qui fournit les services suivants :

  • Création et gestion de l'infrastructure commune des applications.

  • Suivi de la durée de vie des applications et interaction avec celle-ci

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

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

  • Détection des exceptions non gérées et réponse à celles-ci

  • Retour de codes de sortie

  • Gestion des fenêtres dans des applications autonomes (voir Vue d'ensemble des fenêtres WPF)

  • Suivi et gestion de la navigation (voir Vue d'ensemble de la navigation)

Pour utiliser ces services dans votre application, vous devez utiliser la classe Application afin d'implémenter une définition d'application.

Définition d'application.

Une définition d'application WPF est une classe dérivée de Application et est configurée avec un paramètre Microsoft Build Engine (MSBuild) spécial.

Implémentation d'une définition d'application

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

L'exemple suivant indique comment implémenter une définition d'application à l'aide de balises et du fichier code-behind :

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

using System.Windows;  // Application

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

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

  • Dans les balises, l'élément Application doit inclure l'attribut x:Class. Lorsque l'application est générée, l'existence de x:Class dans le fichier de balisage amène MSBuild à créer une classe partial qui dérive de Page et qui porte le nom spécifié par l'attribut x:Class. Cela requiert l'ajout d'une déclaration d'espace de noms XML pour le schéma XAML (xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml").

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

Remarque :

Lorsque vous créez un projet d'application WPF ou un projet d'application de navigateur WPF à l'aide de Microsoft Visual Studio, une définition d'application est incluse par défaut et est définie à l'aide de fichiers de balisage et code-behind.

Ce code est le minimum requis pour implémenter une définition d'application. Toutefois, une configuration MSBuild supplémentaire de la définition d'application est nécessaire 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 du navigateur XAML (XBAP) requièrent l'implémentation d'un certain niveau d'infrastructure avant de pouvoir être exécutées. La partie la plus importante de cette infrastructure est le point d'entrée. Lorsqu'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.

Les développeurs ont toujours dû écrire eux-mêmes une partie, voire l'intégralité, de ce code, selon la technologie employée. En revanche, WPF génère automatiquement ce code lorsque le fichier de balisage de la définition d'application est configuré comme un élément  ApplicationDefinition MSBuild, comme indiqué dans le fichier du projet MSBuild :

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

Étant donné que le fichier code-behind contient le code, il est marqué comme un élément Compile MSBuild, ce qui est normal.

L'application de ces configurations MSBuild aux fichiers de balisage et code-behind d'une définition d'application entraîne la génération du code suivant par MSBuild :

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()
        {


...


        }
    }
}

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 méthode Main pour indiquer que le thread d'interface utilisateur principal de l'application WPF est un thread STA, qui est requis pour les applications WPF. Lorsqu'elle est appelée, la méthode Main crée une instance d'App avant d'appeler la méthode InitializeComponent pour enregistrer les événements et définir les propriétés implémentées dans les balises. Du fait que InitializeComponent soit généré automatiquement, vous n'avez pas besoin d'appeler explicitement InitializeComponent à partir d'une définition d'application comme vous le faites pour les implémentations Page et Window. Enfin, la méthode Run est appelée pour démarrer l'application.

Obtention de l'application actuelle

Étant donné que les services de la classe Application sont partagés dans une application, il ne peut y avoir qu'une seule instance de la classe Application par AppDomain. Pour mettre en œuvre ce principe, la classe Application est implémentée comme une classe Singleton (consultez Implémentation de Singleton en C#), ce qui entraîne la création d'une instance unique de cette classe et fournit un accès partagé à celle-ci avec la propriété static Current.

Le code suivant indique comment acquérir une référence à l'objet Application pour le AppDomain actuel.

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

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

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

Vous pouvez vérifier la valeur de Current à tout moment pendant la durée de vie d'un objet Application. Toutefois, vous devez être vigilant. Après l'instanciation de la classe Application, l'état de l'objet Application est incohérent pendant quelque temps. Pendant cette période, Application effectue diverses tâches d'initialisation nécessaires à l'exécution de votre code, notamment l'établissement de l'infrastructure des applications, la définition des propriétés et l'enregistrement 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 diverses propriétés Application qui sont définies.

Lorsque Application achève son initialisation, sa durée de vie commence véritablement.

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 pour vous tenir informé du moment où votre application a démarré, a été activée et désactivée et arrêtée.

Écran de démarrage

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

Démarrage d'une application

Après que Run a été appelé et l'application initialisée, cette dernière est prête à s'exécuter. Ce moment est signifié par le déclenchement de l'événement Startup :

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

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


...


        }
    }
}

À ce stade de la durée de vie d'une application, une interface utilisateur s'affiche généralement.

Affichage d'une interface utilisateur

La plupart des applications Windows autonomes affichent une Window lorsqu'elles commencent à s'exécuter. Le gestionnaire d'événements Startup est un emplacement à partir duquel vous pouvez effectuer cette opération, comme indiqué par le code suivant.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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();
        }
    }
}
Remarque :

La première Window à instancier dans une application autonome devient par défaut la fenêtre d'application principale. Cet objet Window est référencé par la propriété Application.MainWindow. La valeur de la propriété MainWindow peut être modifiée par programme si une fenêtre différente de la première Window instanciée doit être la fenêtre principale.

Lorsque XBAP démarre en premier, il accèdera très probablement à une Page. Cela est illustré dans le code suivant.

Si vous gérez Startup pour ouvrir uniquement une Window ou naviguer jusqu'à une Page, vous pouvez définir à la place l'attribut StartupUri dans la balise.

L'exemple suivant indique comment utiliser l'StartupUri d'une application autonome pour ouvrir une Window.

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

L'exemple suivant indique comment utiliser un StartupUri à partir de XBAP pour accéder à une Page.

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

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

Remarque :

Pour plus d'informations sur la navigation, consultez Vue d'ensemble de la navigation.

Vous devez gérer l'événement Startup pour ouvrir une Window si vous devez l'instancier à l'aide d'un constructeur non défini par défaut, ou vous devez définir ses propriétés ou vous abonner à ses événements avant de les afficher ou encore vous devez traiter tous les arguments de ligne de commande fournis au lancement de l'application.

Traitement des arguments de ligne de command

Dans Windows, les applications autonomes peuvent être lancées à partir d'une invite de commande ou du Bureau. Dans les deux cas, les arguments de ligne de commande peuvent être passés à l'application. L'exemple suivant illustre une application qui est lancée avec un seul argument de ligne de commande ("/StartMinimized") :

wpfapplication.exe /StartMinimized

Pendant l'initialisation de l'application, WPF extrait les arguments de ligne de commande du système d'exploitation et les transmet au gestionnaire d'événements Startup par le biais de la propriété Args du paramètre StartupEventArgs. Vous pouvez récupérer et stocker les arguments de ligne de commande à l'aide de code similaire à celui décrit ci-dessous.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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();
        }
    }
}

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

Pour un exemple qui illustre une technique d'analyse de ligne de commande plus fiable utilisant des expressions régulières, consultez Traitement d'arguments de ligne de commande, exemple.

Les XBAP ne peuvent pas récupérer et traiter des arguments de ligne de commande car elles sont lancées à l'aide du déploiement de ClickOnce (consultez Déploiement d'une application WPF (WPF)). En revanche, elles peuvent récupérer et traiter des paramètres de chaîne de requête à partir des URL servant à les lancer. Pour obtenir un exemple, consultez Paramètres de chaîne de requête d'un URI, exemple.

Activation et désactivation d'une application

Windows permet aux utilisateurs de passer d'une application à une autre. La méthode la plus courante consiste à utiliser la combinaison de touches ALT+TAB. Il n'est possible de basculer vers une application que si elle a une Window visible qu'un utilisateur peut sélectionner. La fenêtre Window actuellement sélectionnée est la fenêtre active (également appelée fenêtre du premier plan) et il s'agit du Window qui reçoit les entrées d'utilisateur. L'application contenant la fenêtre active est l'application active (ou application du premier plan). Une application devient l'application active dans les circonstances suivantes :

  • Elle est lancée et affiche une Window.

  • Un utilisateur y bascule depuis une autre application en sélectionnant une Window de l'application.

Vous pouvez détecter qu'une application est devenue 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.

  • Lorsque l'application est arrêtée.

Vous pouvez détecter qu'une application est devenue inactive en gérant l'événement Application.Deactivated.

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

<Application 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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;
        }
    }
}

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

Remarque :

Ni Application.Activated ni Application.Deactivated n'est déclenché pour XBAP.

Arrêt d'une application

La vie d'une application s'achève lorsque celle-ci est arrêtée, ce qui peut se produire pour les raisons suivantes :

  • Un utilisateur ferme chaque Window.

  • Un utilisateur ferme la Window principale.

  • Un utilisateur met fin à la session Windows en se déconnectant ou en l'arrêtant.

  • Une condition spécifique à l'application s'est produite.

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

Remarque :

Shutdown ne peut être appelé que dans les applications qui ont UIPermission. Les applications WPF autonomes ont toujours cette autorisation. En revanche, les XBAP qui s'exécutent dans le sandbox de sécurité présentant un niveau de confiance partiel de la zone Internet n'ont pas cette autorisation.

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êtera en attribuant à ShutdownMode l'une des valeurs d'énumération ShutdownMode suivantes :

La valeur par défaut de ShutdownMode est OnLastWindowClose, ce qui signifie qu'une application s'arrête automatiquement lorsque sa dernière fenêtre est fermée par l'utilisateur. Toutefois, si votre application doit s'arrêter lorsque la fenêtre principale est fermée, WPF l'arrête automatiquement si vous affectez à ShutdownMode la valeur OnMainWindowClose. L'exemple suivant le démontre.

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

Si des conditions d'arrêt spécifiques à l'application sont définies, vous affectez à ShutdownMode la valeur OnExplicitShutdown. Dans ce cas, il vous incombe d'arrêter une application en appelant explicitement la méthode Shutdown ; sinon, votre application continuera de s'exécuter même si toutes les fenêtres sont fermées. Notez que Shutdown est appelé implicitement lorsque le ShutdownMode a la valeur OnLastWindowClose ou OnMainWindowClose.

Remarque :

ShutdownMode peut être défini à partir de XBAP, mais il est ignoré ; XBAP est toujours arrêté lorsque l'utilisateur le quitte dans un navigateur ou lorsque le navigateur qui héberge XBAP est fermé. Pour plus d'informations, consultez Vue d'ensemble de la navigation.

Fin de session

Les conditions d'arrêt décrites par la propriété ShutdownMode 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 termine la session Windows en procédant comme suit :

  • Par une déconnexion

  • Par un arrêt

  • Par un redémarrage

  • Par une mise en veille

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="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://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;
            }
        }
    }
}

Dans cet exemple, le code vérifie la propriété ReasonSessionEnding afin de déterminer comment se termine la session Windows. Il utilise cette valeur pour afficher un message de confirmation à l'attention de l'utilisateur. Si ce dernier ne souhaite pas mettre fin à la session, le code attribue à Cancel la valeur true pour empêcher l'arrêt de la session Windows.

Remarque :

SessionEnding n'est pas déclenché pour les XBAP.

Exit

Lorsqu'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. Dans ces cas, vous pouvez gérer l'événement Exit.

<Application
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://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";

Pour accéder à l'intégralité de l'exemple, consultez la rubrique Comment : rendre persistantes et restaurer les propriétés de portée application d'une session d'application à l'autre.

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

  • L'utilisateur quitte XBAP.

  • Dans Internet Explorer 7, l'onglet hébergeant 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 utilisateur. Toutefois, une application peut être lancée par une autre application pour effectuer une tâche spécifique. Lorsque 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 cas, Windows permet aux applications de retourner un code de sortie d'application à l'arrêt. Par défaut, les applications WPF retournent la valeur 0.

Remarque :

Lorsque vous effectuez un débogage à partir de Visual Studio, le code de sortie d'application est affiché dans la fenêtre Sortie à l'arrêt de l'application arrête, dans un message similaire à celui présenté ci-dessous :

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

Vous ouvrez la fenêtre Sortie en cliquant sur Sortie dans le menu Affichage.

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

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

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

Remarque :

Vous pouvez définir le code de sortie à la fois dans les applications autonomes et dans XBAP. Toutefois, la valeur du code de sortie est ignorée pour XBAP.

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.

Notification d'exception non gérée

Pour l'expérience de l'utilisateur, il est préférable d'éviter ce comportement par défaut de l'application en effectuant l'une des opérations suivantes ou toutes :

  • Affichage d'informations conviviales

  • Tentative visant à maintenir une application en cours d'exécution

  • Consignation d'informations conviviales et détaillées sur les exceptions dans le journal d'événements Windows

L'implémentation de cette prise en charge repose sur la possibilité de détecter les exceptions non gérées, ce pourquoi l'événement DispatcherUnhandledException est déclenché.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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;
        }
    }
}
Remarque :

Pour un exemple plus détaillé de la gestion de DispatcherUnhandledException, consultez Exceptions d'application non gérées, exemple.

Un paramètre DispatcherUnhandledExceptionEventArgs contenant des informations contextuelles sur l'exception non gérée, y compris l'exception proprement dite (DispatcherUnhandledExceptionEventArgs.Exception), est transmis au gestionnaire d'événements DispatcherUnhandledException. Vous pouvez utiliser ces informations pour déterminer comment gérer l'exception.

Lorsque vous gérez DispatcherUnhandledException, vous devez affecter à la propriété DispatcherUnhandledExceptionEventArgs.Handled la valeur true ; sinon, WPF considère toujours l'exception comme n'étant pas prise en charge et rétablit le comportement par défaut décrit précédemment. Si une exception non gérée est déclenchée et l'événement DispatcherUnhandledException n'est pas non plus géré, ou l'événement est géré et Handled a la valeur false, l'application s'arrête immédiatement. En outre, aucun autre événement Application n'est déclenché. Par conséquent, vous devez gérer DispatcherUnhandledException si votre application comprend du code qui doit s'exécuter avant son arrêt.

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 la durée de vie d'une application

Les applications autonomes et XBAP n'ont pas exactement la même durée 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.

Application autonome - Événements d'objet Application

De même, la figure suivante illustre les principaux événements de la durée de vie de XBAP et indique l'ordre dans lequel ils sont déclenchés.

XBAP - Événements d'objet Application

Autres services d'application

Outre la gestion de la durée de vie d'une application, Application fournit les services suivants :

  • Propriétés de portée application partagées

  • Ressources de portée application partagées

  • Fichiers de données des ressources, du contenu et du site d'origine d'une application

  • Gestion des fenêtres

  • Gestion de la navigation

Propriétés de portée application partagées

L'application fournit la propriété Properties pour exposer l'état qui peut être partagé dans toute la gamme d'une application. L'exemple suivant illustre l'utilisation des Properties.

// Set an application-scope property with a custom type
CustomType customType = new CustomType();
Application.Current.Properties["CustomType"] = customType;


...


// Get an application-scope property
// NOTE: Need to convert since Application.Properties is a dictionary of System.Object
CustomType customType = (CustomType)Application.Current.Properties["CustomType"];

Pour plus d'informations, consultez :

Ressources de portée application partagées

L'application fournit la propriété Resources pour permettre aux développeurs de partager des ressources d'interface utilisateur dans toute une application. L'exemple suivant illustre l'utilisation des Properties.

// Set an application-scope resource
Application.Current.Resources["ApplicationScopeResource"] = Brushes.White;


...


// Get an application-scope resource
Brush whiteBrush = (Brush)Application.Current.Resources["ApplicationScopeResource"];

Pour plus d'informations, consultez :

Fichiers de données des ressources, du contenu et du site d'origine d'une application

Les applications WPF peuvent gérer plusieurs types de fichiers de données non-code, notamment les fichiers de ressources, les fichiers de contenu et les fichiers de site d'origine. Les méthodes d'assistance suivantes peuvent être utilisées pour charger ces types de fichiers de données :

Gestion des fenêtres

Application et Window entretiennent une étroite relation. Comme vous l'avez vu, la durée de vie d'une application peut dépendre de la durée de vie de ses fenêtres, comme spécifié par la propriété ShutdownMode. Application enregistre la fenêtre désignée comme fenêtre d'application principale (Application.MainWindow) et tient à jour la liste des fenêtres actuellement instanciées (Application.Windows).

Pour plus d'informations, consultez Vue d'ensemble des fenêtres WPF.

Gestion de la navigation

Pour les applications autonomes avec navigation (à l'aide de NavigationWindow et Frame) ou les XBAP, Application détecte toute navigation dans une application et déclenche les événements suivants comme approprié :

En outre, Application permet aux applications, de quelque type qu'elles soient, de créer, de rendre persistants et de récupérer des cookies, à l'aide de GetCookie et SetCookie.

Pour plus d'informations, consultez Vue d'ensemble de la navigation.

Voir aussi

Concepts

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 Windows Presentation Foundation

Référence

Application

Historique des modifications

Date

Historique

Raison

Juillet 2008

Ajout d'une section sur l'utilisation d'un écran de démarrage.

Modifications de fonctionnalités dans le SP1.