Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais

Vue d'ensemble de la navigation

 

Publication: juin 2016

Windows Presentation Foundation (WPF) prend en charge la navigation de style navigateur qui peut être utilisée dans deux types d'applications : les applications autonomes et les XAML browser applications (XBAPs). Pour empaqueter du contenu à des fins de navigation, WPF fournit la classe Page. Vous pouvez naviguer de façon déclarative d'un Page à l'autre en utilisant unHyperlink, ou par programmation en utilisant le NavigationService. WPFutilise le journal pour se souvenir des pages depuis lesquelles l'utilisateur a navigué afin d'y revenir.

Page , Hyperlink, NavigationService et le journal forment le cœur de la prise en charge de la navigation offerte par WPF. Cette vue d'ensemble explore ces fonctionnalités en détail avant de couvrir la prise en charge de la navigation avancée qui inclut la navigation vers les fichiers en langage XAML (eXtensible Application Markup Language) libre, les fichiers HTML et les objets.

System_CAPS_noteRemarque

Dans cette rubrique, le terme « navigateur » désigne uniquement les navigateurs qui peuvent héberger des applications WPF, à savoir Microsoft Internet Explorer et Firefox pour le moment. Lorsque des fonctionnalités WPF spécifiques sont prises en charge uniquement par un navigateur donné, la version du navigateur en question est indiquée.

Cette rubrique fournit une vue d'ensemble des principales fonctionnalités dans WPF. Ces fonctions sont disponibles à la fois aux applications autonomes et XBAP, bien que cette rubrique les présente dans le contexte d'une application XBAP.

System_CAPS_noteRemarque

Cette rubrique n'explique pas comment générer et déployer des XBAP. Pour plus d'informations sur XBAP, consultez Vue d'ensemble des applications de navigateur XAML.

Cette section explique et montre les aspects de navigation suivants :

Dans WPF, vous pouvez naviguer vers plusieurs types de contenu incluant des objets .NET Framework, des objets personnalisés, des valeurs d'énumération, des contrôles utilisateur, des fichiers XAML et des fichiers HTML. Toutefois, vous trouverez que la méthode la plus fréquente et la plus commode pour emballer le contenu consiste à utiliser Page. En outre, Page implémente des fonctionnalités spécifiques à la navigation pour améliorer leur apparence et simplifier le développement.

À l'aide de Page, vous pouvez implémenter de façon déclarative une page navigable de contenu XAML en utilisant une balise comme la suivante.

Une Page implémenté dans la balise XAML a Page comme élément racine et requiert la déclaration d'espace de noms WPFXML. L'élément Page contient le contenu vers lequel vous souhaitez naviguer et que vous voulez afficher. Vous ajoutez le contenu en définissant l'élément de propriété Page.Content, comme représenté dans la balise suivante.

Page.Content peut contenir un seul élément enfant ; dans l'exemple précédent, le contenu est une chaîne unique, « Hello, Page!». Dans la pratique, vous utiliserez généralement un contrôle de disposition comme élément enfant (consultez Disposition) pour contenir et composer votre contenu.

Les éléments enfants d'un élément Page sont considérés comme le contenu d'une Page et, par conséquent, vous n'avez pas besoin d'utiliser la déclaration Page.Content explicite. La balise suivante est l'équivalent déclaratif de l'exemple précédent.

Dans ce cas, Page.Content est défini automatiquement avec les éléments enfants de l'élément Page. Pour plus d'informations, consultez Modèle de contenu WPF.

Un Page de balisage uniquement est utile pour afficher le contenu. Toutefois, une Page peut également afficher des contrôles permettant aux utilisateurs d'interagir avec la page et répondre à l'interaction de l'utilisateur en gérant des événements et en appelant la logique d'application. Une Page interactive est implémentée en utilisant une combinaison de balise et de code-behind, comme représenté dans l'exemple suivant.

Pour permettre à un fichier de balisage et à un fichier code-behind de fonctionner ensemble, la configuration suivante est requise :

  • Dans les balises, l'élément Page 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 Microsoft Build Engine (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="http://schemas.microsoft.com/winfx/2006/xaml"). La classe partial générée implémente InitializeComponent qui appelé pour enregistrer les événements et définir les propriétés implémentées dans la balise.

  • Dans code-behind, la classe doit être une classe partial avec le même nom spécifié par l'attribut x:Class dans la balise et elle doit dériver de Page. 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)).

  • Dans le code-behind, la classe Page doit implémenter un constructeur qui appelle la méthode InitializeComponent. InitializeComponent est implémenté par la classe partial générée du fichier de balisage pour enregistrer les événements et configurer les propriétés définies dans le balisage.

System_CAPS_noteRemarque

Lorsque vous ajoutez une nouvelle Page à votre projet en utilisant Microsoft Visual Studio, Page est implémentée à l'aide de la balise et du code-behind, et inclut la configuration nécessaire pour créer l'association entre les fichiers de balisage et les fichiers code-behind comme décrit ici.

Une fois que vous avez une Page, vous pouvez naviguer vers cette dernière. Pour spécifier la première Page vers laquelle une application navigue, vous devez configurer la Page de démarrage.

XBAP requièrent l'hébergement d'une certaine quantité de l'infrastructure d'application dans un navigateur. Dans WPF, la classe Application fait partie d'une définition d'application qui établit l'infrastructure d'application requise (consultez Vue d'ensemble de la gestion d'applications).

Une définition d'application est généralement implémentée à l'aide d'une balise et du code-behind, avec le fichier de balisage configuré en tant qu'élément MSBuildApplicationDefinition. L'exemple suivant est une définition d'application pour une application XBAP.

Une application XBAP peut utiliser sa définition d'application pour spécifier un Page de démarrage, qui correspond au Page qui est automatiquement chargé lors du lancement de l'application XBAP. Pour ce faire, affectez à la propriété StartupUri l'uniform resource identifier (URI) du Page souhaité.

System_CAPS_noteRemarque

Dans la plupart des cas, la Page est compilée dans ou déployée avec une application. Dans ces cas, l'URI qui identifie une Page est un URI à en-tête pack conforme au modèle pack. Les URIs à en-tête pack sont traités plus loin dans URI à en-tête pack dans WPF. Vous pouvez également naviguer vers du contenu à l'aide du schéma http, comme indiqué ci-dessous.

Vous pouvez définir StartupUri de façon déclarative dans la balise, comme indiqué dans l'exemple suivant.

Dans cet exemple, l'attribut StartupUri est défini avec un URI à en-tête pack relatif qui identifie HomePage.xaml. Lorsque l'application XBAP est lancée, la navigation s'effectue automatiquement vers HomePage.xaml qui s'affiche. L'illustration suivante, qui montre une application XBAP lancée à partir d'un serveur Web, atteste de ce comportement.

Page XBAP
System_CAPS_noteRemarque

Pour plus d'informations sur le développement et le déploiement des applications XBAP, consultez Vue d'ensemble des applications de navigateur XAML et Déploiement d'une application WPF (WPF).

Vous aurez peut-être remarqué dans l'illustration précédente que le titre du volet de navigation et du volet d'onglets est l'URI de l'application XBAP. Outre sa longueur, le titre n'est ni attirant ni informatif. Pour cette raison, Page vous permet de modifier le titre en définissant la propriété WindowTitle. En outre, vous pouvez configurer la largeur et la hauteur de la fenêtre du navigateur en définissant WindowWidth et WindowHeight, respectivement.

WindowTitle, WindowWidth et WindowHeight peuvent être déclarés de façon déclarative dans la balise, comme indiqué dans l'exemple suivant.

Le résultat est affiché dans l'illustration suivante.

Titre de la fenêtre, hauteur, largeur

Une application XBAP classique comprend plusieurs pages. La méthode la plus simple pour naviguer d'une page à une autre consiste à utiliser un Hyperlink. Vous pouvez ajouter de façon déclarative un Hyperlink à une Page en utilisant l'élément Hyperlink représenté dans la balise suivante.

Un élément Hyperlink requiert les éléments suivants :

  • L'URI à en-tête pack de la Page vers laquelle s'effectue la navigation, comme spécifié par l'attribut NavigateUri.

  • Contenu sur lequel un utilisateur peut cliquer pour initialiser la navigation, comme du texte et des images (pour le contenu que l'élément Hyperlink peut contenir, consultez Hyperlink).

L'illustration suivante montre une application XBAP avec une Page qui a un Hyperlink.

Page avec lien hypertexte

Comme vous vous y attendez, cliquer sur Hyperlink amène l'application XBAP à naviguer vers Page identifié par l'attribut NavigateUri. En outre, l'application XBAP ajoute une entrée pour la Page précédente à la liste Pages récentes dans Internet Explorer. Ce cas est représenté dans l'illustration suivante :

Boutons Précédent et Suivant

Outre la prise en charge de la navigation d'une Page à une autre, Hyperlink prend également en charge la navigation vers un fragment.

La navigation vers un fragment est la navigation vers un fragment de contenu dans la Page actuelle ou une autre Page. Dans WPF, un fragment de contenu est le contenu que contient un élément nommé. Un élément nommé est un élément dont l'attribut Name est défini. La balise suivante montre un élément TextBlock nommé qui contient un fragment de contenu.

Pour qu'un Hyperlink navigue vers un fragment de contenu, l'attribut NavigateUri doit inclure les éléments suivants :

  • L'URI du Page avec le fragment de contenu vers lequel naviguer.

  • Un caractère #.

  • Le nom d'élément sur la Page qui contient le fragment de contenu.

Un URI de fragment a le format suivant :

URIPage # NomÉlement

Les éléments suivants affichent un exemple d'un Hyperlink configuré pour naviguer vers un fragment de contenu.

System_CAPS_noteRemarque

Cette section décrit l'implémentation de navigation vers un fragment par défaut dans WPF. WPF vous permet également d'implémenter votre propre schéma de navigation vers un fragment qui, en partie, nécessite la gestion de l'événement NavigationService.FragmentNavigation.

System_CAPS_importantImportant

Vous pouvez naviguer vers des fragments dans des pages XAML libre (fichiers XAML de balisage uniquement avec Page comme élément racine) si les pages peuvent être parcourues via HTTP.

Toutefois, une page XAML libre peut naviguer vers ses propres fragments.

Bien que Hyperlink permette à un utilisateur d'initialiser la navigation vers une Page particulière, le travail de localisation et de téléchargement de la page est exécuté par la classe NavigationService. NavigationService fournit essentiellement la capacité de traiter une requête de navigation pour le compte du code client, tel que le Hyperlink. En outre, NavigationService implémente une prise en charge de niveau supérieur pour suivre et influencer une requête de navigation.

Lors d'un clic sur un Hyperlink, WPF appelle NavigationService.Navigate pour localiser et télécharger la Page à l'URI à en-tête pack spécifié. La Page téléchargée est convertie en une arborescence d'objets dont l'objet racine est une instance de la Page téléchargée. Une référence à l'objet Page racine est stockée dans la propriété NavigationService.Content. L'URI à en-tête pack du contenu consulté est stockée dans la propriété NavigationService.Source, tandis que NavigationService.CurrentSource stocke l'URI à en-tête pack de la dernière page consultée.

System_CAPS_noteRemarque

Il est possible pour une application WPF d'avoir plusieurs NavigationService simultanément actifs. Pour plus d'informations, consultez Hôtes de navigation plus loin dans cette rubrique.

Vous n'avez pas besoin de connaître NavigationService si la navigation est implémentée de façon déclarative dans la balise à l'aide de Hyperlink, parce que Hyperlink utilise le NavigationService pour votre compte. Cela signifie que, tant que le parent direct ou indirect d'un Hyperlink est un hôte de navigation (consultez Hôtes de navigation), le Hyperlink est en mesure de rechercher et d'utiliser le service de navigation de cet hôte pour traiter une requête de navigation.

Toutefois, il existe des situations où vous devez utiliser NavigationService directement, y compris :

  • Lorsque vous devez instancier une Page à l'aide d'un constructeur non défini par défaut.

  • Lorsque vous devez définir des propriétés sur la Page avant de naviguer vers elle.

  • Lorsque la Page qui est la cible de la navigation ne peut être déterminée qu'au moment de l'exécution.

Dans ces situations, vous devez écrire le code pour initialiser la navigation par programmation en appelant la méthode Navigate de l'objet NavigationService. Cela requiert l'obtention d'une référence à NavigationService.

Pour les raisons couvertes dans la section Hôtes de navigation, une application WPF peut avoir plusieurs NavigationService. Cela signifie que votre code a besoin d'une méthode pour rechercher un NavigationService, qui est habituellement le NavigationService qui a navigué vers le Page actif. Vous pouvez obtenir une référence à NavigationService en appelant la méthode static NavigationService.GetNavigationService. Pour obtenir le NavigationService qui a navigué vers une Page particulière, vous passez une référence à la Page comme argument de la méthode GetNavigationService. L'exemple de code suivant montre comment obtenir le NavigationService pour la Page active.

Comme raccourci pour trouver le NavigationService pour une Page, Page implémente la propriété NavigationService. L'exemple suivant le démontre.

System_CAPS_noteRemarque

Une Page peut obtenir une référence à son NavigationService seulement lorsque Page déclenche l'événement Loaded.

L'exemple suivant montre comment utiliser le NavigationService pour naviguer par programmation vers une Page. La navigation par programmation est requise parce que la Page qui est la cible de la navigation ne peut être instanciée qu'à l'aide d'un constructeur unique, non défini par défaut. La Page avec le constructeur non défini par défaut est montrée dans la balise et le code suivants.

La Page qui navigue vers la Page avec le constructeur non défini par défaut est montrée dans la balise et le code suivants.

Lorsque l'utilisateur clique sur le Hyperlink sur ce Page, la navigation est initialisée en instanciant le Page à afficher en utilisant un constructeur non défini par défaut et en appelant la méthode NavigationService.Navigate. Navigate accepte une référence à l'objet auquel NavigationService va accéder, plutôt qu'un URI à en-tête pack.

Si vous devez construire un URI à en-tête pack par programmation (lorsque vous ne pouvez déterminer l'URI à en-tête pack qu'au moment de l'exécution, par exemple), vous pouvez utiliser la méthode NavigationService.Navigate. L'exemple suivant le démontre.

Une Page n'est pas téléchargée si elle a le même URI à en-tête pack que l'URI stocké dans la propriété NavigationService.Source. Pour forcer WPF à télécharger de nouveau la page actuelle, vous pouvez appeler la méthode NavigationService.Refresh, comme représenté dans l'exemple suivant.

Il existe de nombreuses méthodes pour initialiser la navigation, comme vous l'avez vu. Lorsque la navigation est initialisée, et pendant que la navigation est en cours, vous pouvez suivre et influencer la navigation à l'aide des événements suivants implémentés par NavigationService :

  • Navigating. Se produit lorsqu'une nouvelle navigation est demandée. Peut être utilisé pour annuler la navigation.

  • NavigationProgress. Se produit périodiquement pendant un téléchargement pour fournir des informations sur la progression de la navigation.

  • Navigated. . Se produit lorsque la page a été localisée et téléchargée.

  • NavigationStopped. Se produit lorsque la navigation est arrêtée (en appelant StopLoading) ou lorsqu'une nouvelle navigation est demandée alors qu'une navigation est déjà en cours.

  • NavigationFailed. Se produit lorsqu'une erreur est déclenchée au cours de la navigation jusqu'au contenu demandé.

  • LoadCompleted. Se produit lorsque le contenu cible de la navigation est chargé et analysé et que son rendu a commencé.

  • FragmentNavigation. Se produit lorsque la navigation vers un fragment de contenu commence, ce qui survient dans les cas suivants :

    • Immédiatement, si le fragment désiré est dans le contenu actuel.

    • Après avoir chargé le contenu source, si le fragment désiré est dans un contenu différent.

Les événements de navigation sont déclenchés dans l'ordre indiqué par l'illustration suivante.

Graphique de flux de la navigation entre les pages

En général, une Page n'est pas concernée par ces événements. Il est plus probable qu'ils concernent une application et, pour cette raison, ils sont également déclenchés par la classe Application :

À chaque fois que NavigationService déclenche un événement, la classe Application déclenche l'événement correspondant. Frame et NavigationWindow offrent les mêmes événements pour détecter la navigation dans leurs portées respectives.

Dans certains cas, une Page peut s'intéresser à ces événements. Par exemple, un Page peut gérer l'événement NavigationService.Navigating pour déterminer si annuler ou non une navigation qui s'en éloigne. L'exemple suivant le démontre.

Si vous enregistrez un gestionnaire avec un événement de navigation d'une Page, comme dans l'exemple précédent, vous devez également annuler l'enregistrement du gestionnaire d'événements. Si vous ne le faites pas, il peut y avoir des effets secondaires en ce qui concerne la manière dont la navigation WPF se souvient de la navigation Page à l'aide du journal.

WPF utilise deux piles pour se souvenir des pages à partir desquelles vous avez navigué : une pile Back et une pile Forward. Lorsque vous naviguez de la Page actuelle vers un nouvelle Page ou avancez vers une Page existante, la Page actuelle est ajoutée à la pile Back. Lorsque vous naviguez de la Page actuelle vers la Page précédente, la Page actuelle est ajoutée à la pile Forward. La pile Back, la pile Forward et les fonctionnalités pour les gérer sont collectivement appelées le journal. Chaque élément des piles Back et Forward est une instance de la classe JournalEntry et est connu sous le nom d'une entrée de journal.

Du point de vue conceptuel, le journal fonctionne de la même manière que les boutons Précédent et Suivant dans Internet Explorer. Ces boutons sont représentés dans l'illustration ci-dessous.

Boutons Précédent et Suivant

Pour les applications XBAP hébergées par Internet Explorer, WPF intègre le journal dans l'Interface utilisateur de navigation d'Internet Explorer. Cela permet aux utilisateurs de naviguer dans les pages d'une application XBAP à l'aide des boutons Précédent, Suivant etPages récentes dans Internet Explorer. Le journal n'est pas intégré dans Microsoft Internet Explorer 6 de la même manière que dans Internet Explorer 7 ou Internet Explorer 8. À la place, WPF restitue une Interface utilisateur de navigation de substitution.

System_CAPS_importantImportant

Dans Internet Explorer, lorsqu'un utilisateur s'éloigne d'une application XBAP, puis y retourne dans le cadre de sa navigation, seules les entrées de journal pour les pages qui n'ont pas été gardées actives sont conservées dans le journal. Pour savoir comment garder des pages actives, consultez Durée de vie d'une page et le journal plus loin dans cette rubrique.

Par défaut, le texte pour chaque Page qui apparaît dans la liste Pages récentes d'Internet Explorer est l'URI pour la Page. Dans de nombreux cas, ce n'est pas particulièrement explicite pour l'utilisateur. Heureusement, vous pouvez modifier le texte à l'aide d'une des options suivantes :

  1. La valeur de l'attribut JournalEntry.Name attaché.

  2. La valeur de l'attribut Page.Title.

  3. La valeur de l'attribut Page.WindowTitle et l'URI pour la Page actuelle.

  4. L'URI pour la Page actuelle. (Valeur par défaut)

L'ordre dans lequel les options sont répertoriées correspond à l'ordre de priorité pour rechercher le texte. Par exemple, si JournalEntry.Name est défini, les autres valeurs sont ignorées.

L'exemple suivant utilise l'attribut Page.Title pour modifier le texte qui s'affiche pour une entrée de journal.

Bien qu'un utilisateur puisse naviguer dans le journal à l'aide des options Précédent, Suivant et Pages récentes d'Internet Explorer, vous pouvez également naviguer dans le journal à l'aide des mécanismes déclaratifs et de programmation fournis par WPF. Une raison pour ce faire est de fournir des UIs de navigation personnalisées dans vos pages.

Vous pouvez ajouter de façon déclarative la prise en charge de la navigation dans le journal à l'aide des commandes de navigation exposées par NavigationCommands. L'exemple suivant montre comment utiliser la commande de navigation BrowseBack.

Vous pouvez également naviguer par programmation dans le journal à l'aide d'un des membres suivants de la classe NavigationService :

Le journal peut également être manipulé par programmation (consultez Conserver l'état du contenu avec l'historique de navigation plus loin dans cette rubrique).

Considérez une application XBAP avec plusieurs pages contenant du contenu riche, y compris des images, des animations et des médias. L'encombrement mémoire de pages comme celles-ci peut être assez important, en particulier si des médias audio et vidéo sont utilisés. Étant donné que le journal « se souvient » des pages vers lesquelles l'utilisateur a navigué, une telle application XBAP pourrait consommer rapidement une grande quantité de mémoire.

Pour cette raison, le comportement par défaut du journal est de stocker les métadonnées Page dans chaque entrée de journal plutôt qu'une référence à un objet Page. Lorsqu'une entrée de journal est la cible de la navigation, ses métadonnées Page sont utilisées pour créer une nouvelle instance de la Page spécifiée. En conséquence, chaque Page cible de la navigation a la durée de vie illustrée ci-dessous.

Durée de vie de la page

Bien que l'utilisation du comportement de journalisation par défaut puisse économiser de la mémoire, les performances de rendu par page peuvent réduire ; la réinstanciation d'un Page pouvant prendre beaucoup de temps, en particulier si le contenu est volumineux. Si vous devez conserver une instance Page dans le journal, vous pouvez vous inspirer de deux techniques pour ce faire. Tout d'abord, vous pouvez naviguer par programmation vers un objet Page en appelant la méthode NavigationService.Navigate.

Ensuite, vous pouvez spécifier que WPF conserve une instance d'une Page dans le journal en affectant à la propriété KeepAlive la valeur true (la valeur par défaut est false). Comme indiqué dans l'exemple suivant, vous pouvez définir KeepAlive de façon déclarative dans la balise.

La différence de durée de vie entre une Page gardée active est une qui ne l'est pas est subtile. La première fois que l'on navigue vers une Page gardé actif, elle est instanciée tout comme une Page qui n'est pas gardée active. Toutefois, comme une instance de la Page est conservée dans le journal, elle n'est jamais instanciée de nouveau tant qu'elle reste dans le journal. Par conséquent, si une Page a une logique d'initialisation qui doit être appelée chaque fois que l'on navigue vers la Page, vous devez la déplacer du constructeur dans un gestionnaire pour l'événement Loaded. Comme indiqué dans l'illustration suivante, les événements Loaded et Unloaded sont encore déclenchés chaque fois que la navigation s'effectue depuis et vers une Page, respectivement.

Lorsque les événements chargés et déchargés sont déclenchés

Lorsqu'une Page n'est pas gardée active, vous ne devez suivre ni l'une ni l'autre des options suivantes :

  • Stocker une référence la concernant, en tout ou partie.

  • Enregistrer des gestionnaires d'événements avec des événements qu'elle n'implémente pas.

Suivre l'une ou l'autre de ces deux options crée des références qui forcent le stockage de la Page en mémoire, même après sa suppression du journal.

En général, vous devez préférer le comportement de Page par défaut qui consiste à ne pas garder de Page active. Toutefois, cela a des conséquences sur l'état dont nous traiterons dans la section suivante.

Si une Page n'est pas gardée active et qu'elle possède des contrôles qui collectent des données de l'utilisateur, qu'arrive-t-il aux données si un utilisateur s'éloigne de la Page, puis qu'il y retourne ? L'utilisateur, de son côté, s'attend à voir les données qu'il a entrées précédemment. Malheureusement, comme une nouvelle instance de la Page est créée à chaque navigation, les contrôles qui ont collecté les données sont réinstanciés et les données sont perdues.

Heureusement, le journal assure la prise en charge requise pour se souvenir des données issues de la navigation dans les Page, y compris les données de commande. L'entrée de journal pour chaque Page agit spécifiquement comme un conteneur temporaire pour l'état de Page associé. Les étapes suivantes décrivent comment cette prise en charge est utilisée lorsque l'on navigue à partir d'une Page :

  1. Une entrée pour la Page actuelle est ajoutée au journal.

  2. L'état de la Page est stocké avec l'entrée de journal pour cette page et ajouté à la pile Back.

  3. La navigation s'effectue vers la nouvelle Page.

Lorsque la navigation retourne à la page Page, à l'aide du journal, les étapes suivantes sont effectuées :

  1. Le Page (l'entrée de journal du dessus sur la pile Back) est instancié.

  2. La Page est actualisée avec l'état qui était stocké avec l'entrée de journal pour la Page.

  3. La navigation retourne à Page.

WPF utilise automatiquement cette prise en charge lorsque les contrôles suivants sont utilisés sur une Page :

Si une Page utilise ces contrôles, les données qui y sont entrées ne sont pas oubliées au fil de la navigation entre les Page, comme indiqué par la zone de liste Couleur favoriteListBox dans l'illustration suivante.

Page avec contrôles mémorisant l'état

Lorsqu'une Page a des contrôles autres que ceux de la liste précédente, ou lorsque l'état est stocké dans des objets personnalisés, vous devez écrire du code pour faire en sorte que le journal se souvienne de l'état au fil de la navigation entre les Page.

Si vous devez vous souvenir de petites parties d'état au fil de la navigation dans les Page, vous pouvez utiliser des propriétés de dépendance (consultez DependencyProperty) configurées avec l'indicateur de métadonnées FrameworkPropertyMetadata.Journal.

Si l'état dont votre Page doit se souvenir à travers des navigations comprend plusieurs éléments de données, vous aurez peut-être besoin de moins de code pour encapsuler votre état dans une classe unique et implémenter l'interface IProvideCustomContentState.

Si vous devez naviguer à travers différents états d'une Page unique, sans naviguer à partir de la Page elle-même, vous pouvez utiliser IProvideCustomContentState et NavigationService.AddBackEntry.

Pour les applications WPF, les cookies constituent une autre manière de stocker des données. Ils sont créés, mis à jour et supprimés à l'aide des méthodes SetCookie et GetCookie. Les cookies que vous pouvez créer dans WPF sont les mêmes cookies que d'autres types d'applications Web utilisent ; les cookies sont des éléments de données arbitraires qui sont stockés par une application sur un ordinateur client pendant ou à travers des sessions d'application. Les données de cookie prennent généralement la forme d'une paire nom/valeur avec le format suivant.

Nom = Valeur

Lorsque les données sont passées à SetCookie, avec le Uri de l'emplacement pour lequel le cookie doit être défini, un cookie est créé en mémoire et n'est disponible que pendant la durée de la session d'application en cours. Ce type de cookie est connu sous le nom de cookie de session.

Pour stocker un cookie à travers des sessions d'application, une date d'expiration doit être ajoutée au cookie, selon le format suivant :

NOM = VALEUR ; expires=DAY, DD-MMM-YYYY HH:MM:SS GMT

Un cookie avec une date d'expiration est stocké dans le dossier des fichiers Internet temporaires de l'installation Windows actuelle jusqu'à ce que le cookie expire. Un cookie de ce type est connu sous le nom de cookie persistant parce qu'il persiste à travers les sessions d'application.

Vous récupérez tant les cookies de session que les cookies persistants en appelant la méthode GetCookie, en passant l'Uri de l'emplacement où le cookie a été défini avec la méthode SetCookie.

Voici quelques-unes des façons dont les cookies sont pris en charge dans WPF :

  • Les applications autonomes WPF et les applications XBAP peuvent toutes les deux créer et gérer des cookies.

  • L'accès aux cookies créés par une application XBAP s'effectue à partir du navigateur.

  • Des applications XBAP du même domaine peuvent créer et partager des cookies.

  • Des pages XBAP et HTML du même domaine peuvent créer et partager des cookies.

  • Les cookies sont distribués lorsque des pages XBAP et des pages XAML libre adressent des requêtes Web.

  • Les pages XBAP de niveau supérieur et XBAP hébergé dans IFRAMES peuvent toutes deux accéder aux cookies.

  • La prise en charge des cookies dans WPF est la même pour tous les navigateurs pris en charge.

  • Dans Internet Explorer, la stratégie P3P qui concerne les cookies est honorée par WPF, en particulier en ce qui concerne les applications XBAP internes ou tierces.

Si vous devez passer des données d'une Page à une autre, vous pouvez passer les données comme arguments à un constructeur non défini par défaut de la Page. Notez que si vous utilisez cette technique, vous devez garder la Page active ; sinon, la prochaine fois que vous naviguez vers la Page, WPF la réinstancie en utilisant le constructeur par défaut.

Votre Page peut également implémenter des propriétés définies avec les données qui doivent être passées. Toutefois, cela se complique lorsqu'une Page doit repasser des données à la Page qui a navigué jusqu'à elle. Le problème est que la navigation ne prend en charge aucun mécanisme en mode natif pour garantir le retour à une Page qui vient juste de faire l'objet d'un accès. Fondamentalement, la navigation ne prend pas en charge la sémantique d'appel/retour. Pour résoudre ce problème, WPF fournit la classe PageFunction<T> que vous pouvez utiliser pour garantir le retour à une Page de façon prédictible et structurée. Pour plus d'informations, consultez Vue d'ensemble de la navigation structurée.

Jusqu'à présent, vous avez découvert la gamme des services de navigation que vous êtes le plus susceptible d'utiliser pour générer des applications au contenu navigable. Ces services ont été abordés dans le cadre des applications XBAP, même s'ils ne se limitent pas aux applications XBAP. Les systèmes d'exploitation et les applications Windows modernes tirent parti de l'expérience acquise avec les navigateurs par les utilisateurs modernes pour incorporer une navigation de style navigateur dans des applications autonomes. En voici quelques exemples courants :

  • Dictionnaire des synonymes : pour naviguer parmi un choix de mots.

  • Explorateur de fichiers : pour naviguer parmi des fichiers et dossiers.

  • Assistant : pour décomposer une tâche complexe en plusieurs pages entre lesquelles il est possible de naviguer. Un exemple est l'Assistant Composants de Windows qui gère l'ajout et la suppression de fonctionnalités Windows.

Pour incorporer la navigation de type navigateur dans vos applications autonomes, vous pouvez utiliser la classe NavigationWindow. NavigationWindow dérive de Window et l'étend pour offrir la même prise en charge de navigation que celle fournie par les applications XBAP. Vous pouvez utiliser NavigationWindow comme fenêtre principale de votre application autonome ou comme fenêtre secondaire (boîte de dialogue, par exemple).

Pour implémenter une classe NavigationWindow, comme avec la plupart des classes de premier niveau dans WPF (Window, Page, etc.), vous utilisez une combinaison de balises et de code-behind. L'exemple suivant le démontre.

Ce code crée une NavigationWindow qui navigue automatiquement vers une Page (HomePage.xaml) lorsque la NavigationWindow est ouverte. Si la NavigationWindow est la fenêtre d'application principale, vous pouvez utiliser l'attribut StartupUri pour la lancer. Ce cas est illustré dans la balise suivante :

L'illustration suivante montre la NavigationWindow comme fenêtre principale d'une application autonome.

Fenêtre principale

Dans l'illustration, vous pouvez voir que la NavigationWindow a un titre, bien qu'il n'ait pas été défini dans le code d'implémentation NavigationWindow de l'exemple précédent. À la place, le titre est défini à l'aide de la propriété WindowTitle, qui figure dans le code suivant.

La définition des propriétés WindowWidth et WindowHeight affecte aussi la NavigationWindow.

Habituellement, vous implémentez votre propre NavigationWindow lorsque vous devez personnaliser son comportement ou son apparence. Si vous faites ni l'un ni l'autre, vous pouvez utiliser un raccourci. Si vous spécifiez l'URI à en-tête pack d'une Page comme StartupUri dans une application autonome, Application crée automatiquement une NavigationWindow pour héberger la Page. La balise suivante indique comment y parvenir.

Si vous souhaitez qu'une fenêtre d'application secondaire telle qu'une boîte de dialogue soit une NavigationWindow, vous pouvez utiliser le code dans l'exemple suivant pour l'ouvrir.

L'illustration suivante affiche le résultat.

Boîte de dialogue

Comme vous pouvez le voir, NavigationWindow affiche des boutons Précédent et Suivant de style Internet Explorer qui permettent aux utilisateurs de naviguer dans le journal. Ces boutons fournissent les mêmes fonctions à l'utilisateur, comme indiqué dans l'illustration suivante.

Boutons Précédent et Suivant dans une fenêtre de navigation

Si vos pages fournissent leur propre interface utilisateur et prise en charge de navigation dans le journal, vous pouvez masquer les boutons Précédent et Suivant affichés par NavigationWindow en affectant à la propriété ShowsNavigationUI la valeur false.

Vous pouvez également utiliser la prise en charge de la personnalisation dans WPF pour remplacer l'Interface utilisateur de la NavigationWindow elle-même.

Le navigateur et NavigationWindow sont tous deux des fenêtres qui hébergent du contenu navigable. Dans certains cas, les applications ont un contenu qui n'a pas besoin d'être hébergé par une fenêtre entière. À la place, ce contenu sera hébergé à l'intérieur d'un autre contenu. Vous pouvez insérer du contenu navigable dans autre contenu à l'aide de la classe Frame. Frame assure la même prise en charge que NavigationWindow et XBAP.

L'exemple suivant montre comment ajouter un Frame à une Page de manière déclarative à l'aide de l'élément Frame.

Cette balise définit l'attribut Source de l'élément Frame avec un URI à en-tête pack pour la Page vers laquelle Frame doit naviguer initialement. L'illustration suivante montre une application XBAP avec une Page qui a un Frame qui a navigué entre plusieurs pages.

Frame ayant subi une navigation entre plusieurs pages

Vous ne devez pas seulement utiliser Frame à l'intérieur du contenu d'une Page. Il est également commun d'héberger un Frame à l'intérieur du contenu d'une Window.

Par défaut, Frame utilise seulement son propre journal en l'absence d'un autre journal. Si un Frame fait partie du contenu hébergé dans un NavigationWindow ou un XBAP, Frame utilise le journal qui appartient au NavigationWindow ou à l'application XBAP. Il arrive parfois qu'un Frame doive être responsable de son propre journal. Une raison pour ce faire est de permettre la navigation dans le journal à l'intérieur des pages hébergées par un Frame. L'exemple suivant illustre ce propos :

Diagramme de frame et de page

Dans ce cas, vous pouvez configurer le Frame pour utiliser son propre journal en affectant à la propriété JournalOwnership du Frame la valeur OwnsJournal. Ce cas est illustré dans la balise suivante :

L'exemple suivant illustre l'effet de la navigation dans un Frame qui utilise son propre journal.

Frame utilisant son propre journal

Remarquez que les entrées de journal sont affichées par l'Interface utilisateur de navigation dans le Frame, plutôt que par Internet Explorer.

System_CAPS_noteRemarque

Si un Frame fait partie du contenu hébergé dans une Window, Frame utilise son propre journal et, par conséquent, affiche sa propre Interface utilisateur de navigation.

Si votre expérience utilisateur requiert qu'un Frame fournisse son propre journal sans afficher l'Interface utilisateur de navigation, vous pouvez masquer l'Interface utilisateur de navigation en affectant à NavigationUIVisibility la valeur Hidden. Ce cas est illustré dans la balise suivante :

Frame et NavigationWindow sont des classes appelées hôtes de navigation. Un hôte de navigation est une classe qui peut naviguer vers un contenu et l'afficher. Pour ce faire, chaque hôte de navigation utilise son propre NavigationService et journal. La construction de base d'un hôte de navigation est illustrée ci-dessous.

Diagrammes du navigateur

Fondamentalement, cela permet à NavigationWindow et Frame de fournir la même prise en charge de navigation qu'une application XBAP lorsqu'elle est hébergée dans le navigateur.

Outre l'utilisation de NavigationService et d'un journal, les hôtes de navigation implémentent les mêmes membres que NavigationService. L'exemple suivant illustre ce propos :

Journal dans un frame et dans une fenêtre de navigation

Cela vous permet de programmer la prise en charge de navigation directement sur eux. Vous pouvez en tenir compte si vous devez fournir une Interface utilisateur de navigation personnalisée pour un Frame hébergé dans un Window. De plus, les deux types implémentent des membres supplémentaires associés à la navigation, notamment BackStack (NavigationWindow.BackStack, Frame.BackStack) et ForwardStack (NavigationWindow.ForwardStack, Frame.ForwardStack), qui vous permettent d'énumérer les entrées de journal dans les piles Back et Forward respectivement.

Comme mentionné précédemment, plusieurs journaux peuvent exister dans une application. L'exemple suivant illustre ce cas de figure.

Plusieurs journaux au sein d'une application

Partout dans cette rubrique, Page et les XBAP à en-tête pack ont été utilisés pour montrer les diverses fonctionnalités de navigation de WPF. Toutefois, une Page compilée dans une application n'est pas le seul type de contenu vers lequel on peut naviguer et les XBAP à en-tête pack ne sont pas la seule méthode pour identifier un contenu.

Comme illustré dans cette section, vous pouvez également naviguer vers des fichiers XAML libre, des fichiers HTML et des objets.

Un fichier XAML libre est un fichier présentant les caractéristiques suivantes :

  • Il contient uniquement du langage XAML (autrement dit, aucun code).

  • Il possède une déclaration d'espace de noms appropriée.

  • Son nom de fichier possède une extension .xaml.

Par exemple, considérez le contenu suivant stocké comme un fichier XAML libre, Person.xaml.

Lorsque vous double-cliquez sur le fichier, le navigateur s'ouvre et navigue vers son contenu qu'il affiche. Ce cas est représenté dans l'illustration suivante :

Affichage du contenu du fichier Person.XAML

Vous pouvez afficher un fichier en XAML libre à partir des éléments suivants :

  • Un site Web sur l'ordinateur local, l'intranet ou Internet.

  • Un partage de fichiers Universal Naming Convention (UNC).

  • Le disque local.

Un fichier en XAML libre peut être ajouté aux favoris du navigateur ou constituer la page d'accueil du navigateur.

System_CAPS_noteRemarque

Pour plus d'informations sur la publication et le lancement de pages en XAML libre, consultez Déploiement d'une application WPF (WPF).

Une limitation relative au XAML libre est que vous pouvez uniquement héberger du contenu exécutable à un niveau de confiance partielle. Par exemple, Window ne peut pas être l'élément racine d'un fichier en XAML libre. Pour plus d'informations, consultez Sécurité de confiance partielle de WPF.

Comme vous pouvez vous y attendre, vous pouvez également naviguer vers des fichiers HTML. Vous devez simplement fournir un URI qui utilise la méthode http. Par exemple, le XAML suivant montre un Frame qui navigue vers une page HTML.

La navigation vers du contenu HTML requiert des autorisations spéciales. Par exemple, vous ne pouvez pas naviguer à partir d'une application XBAP qui s'exécute dans le bac à sable (sandbox) de sécurité de confiance partielle de la zone Internet. Pour plus d'informations, consultez Sécurité de confiance partielle de WPF.

Le contrôle WebBrowser prend en charge l'hébergement de document HTML, la navigation et l'interopérabilité de script/code managé. Pour plus d'informations sur le contrôle WebBrowser, consultez WebBrowser.

Comme pour Frame, la navigation vers le HTML à l'aide de WebBrowser requiert des autorisations spéciales. Par exemple, à partir d'une application de confiance partielle, vous ne pouvez naviguer que vers le HTML se trouvant sur le site d'origine. Pour plus d'informations, consultez Sécurité de confiance partielle de WPF.

Si vous avez des données stockées comme objets personnalisés, une façon d'afficher ces données est de créer une Page avec un contenu lié à ces objets (consultez Vue d'ensemble de la liaison de données). Si vous n'avez pas besoin de la charge additionnelle liée à la création d'une page entière simplement pour afficher les objets, vous pouvez naviguer directement vers eux à la place.

Considérez la classe Person implémentée dans le code suivant.

Pour naviguer vers elle, vous appelez la méthode NavigationWindow.Navigate, comme indiqué dans le code suivant.

L'illustration suivante affiche le résultat.

Page de navigation vers une classe

Dans cette illustration, vous pouvez voir que rien d'utile n'est affiché. En fait, la valeur affichée est la valeur de retour de la méthode ToString pour l'objet Person ; par défaut, c'est la seule valeur que WPF peut utiliser pour représenter votre objet. Vous pourriez remplacer la méthode ToString pour retourner des informations plus explicites, bien qu'il ne s'agira encore que d'une valeur de chaîne. Une autre technique permettant de tirer partir des fonctionnalités de présentation de WPF consiste à utiliser un modèle de données. Vous pouvez implémenter un modèle de données que WPF peut associer à un objet d'un type particulier. Le code suivant montre un modèle de données pour l'objet Person.

Ici, le modèle de données est associé au type Person en utilisant l'extension de balisage x:Type dans l'attribut DataType. Le modèle de données lie ensuite des éléments TextBlock (consultez TextBlock) aux propriétés de la classe Person. L'illustration suivante montre l'apparence de l'objet Person après mise à jour.

Navigation vers une classe comportant un modèle de données

Un des avantages de cette technique est de pouvoir afficher vos objets de manière cohérente en tout point de votre application grâce à la réutilisation du modèle de données.

Pour plus d'informations sur les modèles de données, consultez Vue d'ensemble des modèles de données.

La prise en charge de la navigation WPF permet de naviguer dans les applications XBAP sur Internet et permet aux applications d'héberger du contenu tiers. Pour protéger les applications et les utilisateurs de comportements malfaisants, WPF fournit diverses fonctionnalités de sécurité couvertes dans Sécurité (WPF) et Sécurité de confiance partielle de WPF.

Afficher: