Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction automatique. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

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 de la fonctionnalité dans la classe d' Application pour créer et gérer des applications.

Cette rubrique comprend les sections suivantes.

Dans WPF, les fonctionnalités communes de portée application sont encapsulées dans la classe d' Application . La classe d' Application inclut les fonctionnalités suivantes :

  • 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

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

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

  • La gestion des fenêtres dans des applications autonomes.

  • Suivi et gestion de la navigation.

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

Tâche

Approche

obtenez un objet qui représente l'application actuelle

Utilisez la propriété Application.Current.

ajoutez un écran de démarrage à une application

Consultez Comment : ajouter un écran de démarrage dans une application WPF.

Démarrez une application

Utilisez la méthode Application.Run.

Arrêt d'une application

Use la méthode Shutdown de l'objet Application.Current.

Arguments get de la ligne de commande

gérez l'événement d' Application.Startup et utilisez la propriété d' StartupEventArgs.Args . Pour obtenir un exemple, consultez l'événement d' Application.Startup .

Obtenez ou définissez le code de sortie d'application

Définissez la propriété d' ExitEventArgs.ApplicationExitCode dans le gestionnaire d'événements d' Application.Exit ou appelez la méthode d' Shutdown et passez un entier.

Le détecter et répondre aux exceptions non gérées

Gérer l'événement DispatcherUnhandledException.

Get et ressources de portée application lors ensemble

Utilisez la propriété Application.Resources.

utilisez un dictionnaire de ressources de portée application

Consultez Comment : utiliser un dictionnaire de ressources de portée application.

Get et propriétés de portée application d'ensemble

Utilisez la propriété Application.Properties.

Passez et enregistrez l'état d'une application

Consultez Comment : rendre persistantes et restaurer les propriétés de portée application d'une session d'application à l'autre.

Gérer les fichiers de données non-code, notamment les fichiers de ressources, les fichiers de contenu, et les fichiers de ressources.

Consultez Fichiers de ressources, de contenu et de données d'une application WPF.

Gestion des fenêtres dans des applications autonomes

Consultez Vue d'ensemble des fenêtres WPF.

Suivez et gestion de la navigation

Consultez Vue d'ensemble de la navigation.

Pour utiliser les fonctionnalités de la classe d' Application , vous devez implémenter une 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.

ms743714.collapse_all(fr-fr,VS.110).gifImplé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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  x:Class="SDKSample.App" />




Imports Microsoft.VisualBasic
Imports System.Windows ' Application

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



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 Application 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="http://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 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.

ms743714.collapse_all(fr-fr,VS.110).gifConfiguration 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="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 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 principal interface utilisateur de l'application WPF est un thread STA, qui est requis pour les applications WPF. Lorsqu'elle est appelée, Main crée une nouvelle instance de App avant l'appel de la méthode InitializeComponent pour enregistrer les événements et définir les propriétés qui sont implémentées dans le balisage. 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.

Étant donné que les fonctionnalités de la classe d' Application sont partagées entre une application, il peut y avoir qu'une seule instance de la classe d' 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.

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.

Cette section comprend les sous-sections suivantes.

ms743714.collapse_all(fr-fr,VS.110).gifÉ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.

ms743714.collapse_all(fr-fr,VS.110).gifDé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.

ms743714.collapse_all(fr-fr,VS.110).gifAffichage 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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App" 
  Startup="App_Startup" />




Imports Microsoft.VisualBasic
Imports System.Windows ' Application, StartupEventArgs

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



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


RemarqueRemarque

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.


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




Imports System ' Uri, UriKind, EventArgs, Console
Imports System.Windows ' Application, StartupEventArgs
Imports System.Windows.Navigation ' NavigationWindow

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



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


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="http://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="http://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.

RemarqueRemarque

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.

ms743714.collapse_all(fr-fr,VS.110).gifTraitement 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 la 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

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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  Startup="App_Startup" />




Imports Microsoft.VisualBasic
Imports System.Windows ' Application, StartupEventArgs, WindowState

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



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

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.

ms743714.collapse_all(fr-fr,VS.110).gifActivation et désactivation d'une application

Windows autorise les utilisateurs à passer d'une application à l'autre. La façon 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 Window actuellement sélectionnée est la fenêtre active (également appelée fenêtre de premier plan) et constitue la Window recevant les entrées d'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 :

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




Imports Microsoft.VisualBasic
Imports System ' EventArgs
Imports System.Windows ' Application

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



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.

RemarqueRemarque

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

ms743714.collapse_all(fr-fr,VS.110).gifArrê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.

RemarqueRemarque

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.

ms743714.collapse_all(fr-fr,VS.110).gifMode 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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://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.

RemarqueRemarque

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.

ms743714.collapse_all(fr-fr,VS.110).gifFin 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="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" />




Imports Microsoft.VisualBasic
Imports System.Windows ' Application, SessionEndingCancelEventArgs, MessageBox, MessageBoxResult, MessageBoxButton

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



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.

RemarqueRemarque

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

ms743714.collapse_all(fr-fr,VS.110).gifExit

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



Imports System.IO ' StreamReader, FileMode
Imports System.IO.IsolatedStorage ' IsolatedStorageFile, IsolatedStorageFileStream

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



...


		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



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


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

ms743714.collapse_all(fr-fr,VS.110).gifCode 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 de sortie de code 0.

RemarqueRemarque

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.

RemarqueRemarque

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.

ms743714.collapse_all(fr-fr,VS.110).gifExceptions 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="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" />




Imports Microsoft.VisualBasic
Imports System.Windows ' Application
Imports System.Windows.Threading ' DispatcherUnhandledExceptionEventArgs

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



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


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.

ms743714.collapse_all(fr-fr,VS.110).gifÉvénements de la durée de vie d'une application

Les applications autonomes et XBAP n'ont pas exactement les mêmes durées de vie. L'illustration suivante montre les événements de touche dans la durée de vie d'une application autonome et indique la séquence dans laquelle 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

Ajouts de la communauté

AJOUTER
Afficher:
© 2015 Microsoft