Vue d'ensemble de la navigation

  • Article

Mise à jour : Juillet 2008

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 applications du navigateur XAML (XBAP). Pour empaqueter du contenu à des fins de navigation, WPF fournit la classe Page. Vous pouvez naviguer d'un Page à un autre de façon déclarative à l'aide d'un Hyperlink ou par programmation à l'aide du NavigationService. WPF utilise le journal pour mémoriser les pages qui ont fait l'objet d'une navigation et y retourner.

Page, Hyperlink, NavigationService et le journal forment le cœur de la prise en charge de la navigation offert 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 des fichiers XAML (Extensible Application Markup Language) libre, des fichiers HTML et des objets.

Remarque :

Dans cette rubrique, le terme « navigateur » fait uniquement référence aux navigateurs pouvant héberger des applications WPF, ce qui inclut actuellement Internet Explorer 7, Microsoft Internet Explorer 6 et Firefox 2.0 +. Lorsque des fonctionnalités WPF spécifiques ne sont prises en charge que par un navigateur donné, la version du navigateur est indiquée.

Cette rubrique comprend les sections suivantes.

  • Navigation dans les applications WPF
  • La classe NavigationWindow
  • La classe Frame
  • Hôtes de navigation
  • Navigation vers un autre contenu que des pages XAML
  • Sécurité
  • Rubriques connexes

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.

Remarque :

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

Cette section explique et montre les aspects de navigation suivants :

  • Implémentation d'une page

  • Configuration d'une page de démarrage

  • Configuration du titre, de la largeur et de la hauteur de la fenêtre hôte

  • Navigation par lien hypertexte

  • Navigation vers un fragment

  • Service de navigation

  • Navigation par programme avec le service de navigation

  • Durée de vie de la navigation

  • Mémorisation de la navigation avec le journal

  • Durée de vie d'une page et le journal

  • Conserver l'état du contenu avec l'historique de navigation

  • Cookies

  • Navigation structurée

Implémentation d'une page

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.

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

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 xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation">
  <Page.Content>
    <!-- Page Content -->
    Hello, Page!
  </Page.Content>
</Page>

Page.Content ne peut contenir qu'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 pour l'élément enfant (consultez Système de 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.

<Page xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation">
  <!-- Page Content -->
  Hello, Page!
</Page>

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="https://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 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 par le fichier de balisage pour enregistrer les événements et les propriétés définis dans la balise.

Remarque :

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.

Configuration d'une 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 ApplicationDefinition MSBuild. 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'URI (Uniform Resource Identifier) du Page souhaité.

Remarque :

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 URI à en-tête pack sont traités plus loin dans URI à en-tête pack dans Windows Presentation Foundation. 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.

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

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. Ceci est démontré par l'illustration suivante, qui montre une application XBAP lancée à partir d'un serveur Web.

Page XBAP

Remarque :

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

Configuration du titre, de la largeur et de la hauteur de la fenêtre hôte

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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.HomePage"
    WindowTitle="Page Title"
    WindowWidth="500"
    WindowHeight="200">
  Hello, from the XBAP HomePage!
</Page>

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 est d'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.

<Page
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  WindowTitle="Page With Hyperlink"
  WindowWidth="250"
  WindowHeight="250">


...


<Hyperlink NavigateUri="UriOfPageToNavigateTo.xaml">
  Navigate to Another Page
</Hyperlink>


...


</Page>

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

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    WindowTitle="Page With Fragments" >


...


<!-- Content Fragment called "Fragment1" -->
<TextBlock Name="Fragment1">
  Ea vel dignissim te aliquam facilisis ...
</TextBlock>


...


</Page>

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 :

PageURI#ElementName

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

<Page
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  WindowTitle="Page That Navigates To Fragment" >


...


<Hyperlink NavigateUri="PageWithFragments.xaml#Fragment1">
  Navigate To pack Fragment
</Hyperlink>


...


</Page>

Pour obtenir un exemple complet de navigation vers un fragment, consultez Navigation vers un fragment, exemple.

Remarque :

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

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.

Service de navigation

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 pour le contenu cible de la navigation est stocké dans la propriété NavigationService.Source, alors que NavigationService.CurrentSource stocke l'URI à en-tête pack pour la dernière page cible de la navigation.

Remarque :

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 programme en appelant la méthode Navigate de l'objet NavigationService. Cela requiert l'obtention d'une référence à NavigationService.

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 à un 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.

using System.Windows.Navigation; // NavigationServce


...


// Get a reference to the NavigationService that navigated to this Page
NavigationService ns = NavigationService.GetNavigationService(this);

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

using System.Windows.Navigation; // NavigationServce


...


// Get a reference to the NavigationService that navigated to this Page
NavigationService ns = this.NavigationService;
Remarque :

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

Navigation par programme vers un objet page

L'exemple suivant montre comment utiliser le NavigationService pour naviguer par programme vers une Page. La navigation par programme 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.

<Page
    x:Class="SDKSample.PageWithNonDefaultConstructor"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    Title="PageWithNonDefaultConstructor">

  <!-- Content goes here -->

</Page>

using System.Windows.Controls; // Page

namespace SDKSample
{
    public partial class PageWithNonDefaultConstructor : Page
    {
        public PageWithNonDefaultConstructor(string message)
        {
            InitializeComponent();

            this.Content = message;
        }
    }
}

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.

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

  <Hyperlink Click="hyperlink_Click">
    Navigate to Page with Non-Default Constructor
  </Hyperlink>

</Page>

using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService

namespace SDKSample
{
    public partial class NSNavigationPage : Page
    {
        public NSNavigationPage()
        {
            InitializeComponent();
        }

        void hyperlink_Click(object sender, RoutedEventArgs e)
        {
            // Instantiate the page to navigate to
            PageWithNonDefaultConstructor page = new PageWithNonDefaultConstructor("Hello!");

            // Navigate to the page, using the NavigationService
            this.NavigationService.Navigate(page);
        }
    }
}

Un clic sur Hyperlink sur cette Page, initialise la navigation en instanciant la Page vers laquelle naviguer à l'aide du constructeur non défini par défaut et en appelant la méthode NavigationService.Navigate. Navigate accepte une référence à l'objet vers lequel le NavigationService naviguera, plutôt qu'un URI à en-tête pack.

Si vous devez construire un URI à en-tête pack par programme (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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.NSUriNavigationPage">
  <Hyperlink Click="hyperlink_Click">Navigate to Page by Pack URI</Hyperlink>
</Page>

using System; // Uri, UriKind
using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService

namespace SDKSample
{
    public partial class NSUriNavigationPage : Page
    {
        public NSUriNavigationPage()
        {
            InitializeComponent();
        }

        void hyperlink_Click(object sender, RoutedEventArgs e)
        {
            // Create a pack URI
            Uri uri = new Uri("AnotherPage.xaml", UriKind.Relative);

            // Get the navigation service that was used to 
            // navigate to this page, and navigate to 
            // AnotherPage.xaml
            this.NavigationService.Navigate(uri);
        }
    }
}

Actualisation de la page active

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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.NSRefreshNavigationPage">
 <Hyperlink Click="hyperlink_Click">Refresh this page</Hyperlink>
</Page>

using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService

namespace SDKSample
{
    public partial class NSRefreshNavigationPage : Page
    {


...


        void hyperlink_Click(object sender, RoutedEventArgs e)
        {
            // Force WPF to download this page again
            this.NavigationService.Refresh();
        }
    }
}

Durée de vie de la navigation

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 à la demande d'une nouvelle navigation. Peut être utilisé pour annuler la navigation.

  • NavigationProgress. Se produit périodiquement pendant un téléchargement pour fournir des informations de 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 vers le 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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.CancelNavigationPage">
  <Button Click="button_Click">Navigate to Another Page</Button>
</Page>

using System; // Uri, UriKind
using System.Windows; // RoutedEventArgs, MessageBox, MessageBoxResult
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService, NavigatingCancelEventArgs

namespace SDKSample
{
    public partial class CancelNavigationPage : Page
    {
        public CancelNavigationPage()
        {
            InitializeComponent();

            // Can only access the NavigationService when the page has been loaded
            this.Loaded += new RoutedEventHandler(CancelNavigationPage_Loaded);
            this.Unloaded += new RoutedEventHandler(CancelNavigationPage_Unloaded);
        }

        void button_Click(object sender, RoutedEventArgs e)
        {
            // Force WPF to download this page again
            this.NavigationService.Navigate(new Uri("AnotherPage.xaml", UriKind.Relative));
        }

        void CancelNavigationPage_Loaded(object sender, RoutedEventArgs e)
        {
            this.NavigationService.Navigating += new NavigatingCancelEventHandler(NavigationService_Navigating);
        }

        void CancelNavigationPage_Unloaded(object sender, RoutedEventArgs e)
        {
            this.NavigationService.Navigating -= new NavigatingCancelEventHandler(NavigationService_Navigating);
        }

        void NavigationService_Navigating(object sender, NavigatingCancelEventArgs e)
        {
            // Does the user really want to navigate to another page?
            MessageBoxResult result;
            result = MessageBox.Show("Do you want to leave this page?", "Navigation Request", MessageBoxButton.YesNo);

            // If the user doesn't want to navigate away, cancel the navigation
            if (result == MessageBoxResult.No) e.Cancel = true;
        }
    }
}

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.

Mémorisation de la navigation avec le 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 7. 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 7, WPF intègre le journal dans l'interface utilisateur de navigation d'Internet Explorer 7. Cela permet aux utilisateurs de naviguer dans les pages d'une application XBAP à l'aide des boutons Précédent, Suivant et Pages récentes dans Internet Explorer 7. Le journal n'est pas intégré dans Microsoft Internet Explorer 6 de la même manière que dans Internet Explorer 7. À la place, WPF restitue une interface utilisateur de navigation de substitution.

Remarque importante :

Dans Internet Explorer 7, 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 un plus d'informations sur la manière de 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 7 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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.PageWithTitle"
    Title="This is the title of the journal entry for this page.">


...


</Page>

using System.Windows.Controls; // Page

namespace SDKSample
{
    public partial class PageWithTitle : Page
    {


...


    }
}

Bien qu'un utilisateur puisse naviguer dans le journal à l'aide des options Précédent, Suivant et Pages récentes dans Internet Explorer 7, 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 interfaces utilisateur 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.

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


...


<Hyperlink Command="NavigationCommands.BrowseBack">Back</Hyperlink>


...


</Page>

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

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

Durée de vie d'une page et le journal

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. Comme le journal « se souvient » des pages vers lesquelles on 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 programme 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.

<Page
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.KeepAlivePage"
    KeepAlive="True">

  An instance of this page is stored in the journal.

</Page>

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.

Conserver l'état du contenu avec l'historique de navigation

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. Pour obtenir un exemple, consultez Mémoriser un seul élément d'état pour plusieurs instances d'une page.

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. Consultez Mémoriser un seul ensemble d'états pour plusieurs instances d'une page).

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. Consultez Mémoriser plusieurs ensembles d'états par instance de page).

Cookies

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.

Name=Value

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 :

NAME=VALUE; 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.

Remarque :

Pour obtenir un exemple qui montre comment utiliser les méthodes SetCookie et GetCookie pour créer et récupérer des cookies d'une application WPF, consultez Cookies d'application, exemple.

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 (Internet Explorer 7, Microsoft Internet Explorer 6 et Firefox 2.0+).

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

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.

La classe NavigationWindow

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 une navigation de style navigateur dans vos applications autonomes, vous pouvez utiliser la classe NavigationWindow. NavigationWindow dérive de Window et la prolonge avec la même prise en charge de navigation que 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.

<NavigationWindow
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.MainWindow" 
    Source="HomePage.xaml"/>

using System.Windows.Navigation; // NavigationWindow

namespace SDKSample
{
    public partial class MainWindow : NavigationWindow
    {
        public MainWindow()
        {
            InitializeComponent();
        }
    }
}

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 :

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

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.

<Page 
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    Title="Home Page"
    WindowTitle="NavigationWindow">


...


</Page>

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.

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

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.

// Open a navigation window as a dialog box
NavigationWindowDialogBox dlg = new NavigationWindowDialogBox();
dlg.Source = new Uri("HomePage.xaml", UriKind.Relative);
dlg.Owner = this;
dlg.ShowDialog();

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 7 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. Pour obtenir un exemple de cette procédure, consultez Interface utilisateur NavigationWindow personnalisée, exemple.

La classe Frame

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 le contenu navigable dans un autre contenu en utilisant la classe Frame qui fournit 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.

<Page 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  WindowTitle="Page that Hosts a Frame"
  WindowWidth="250"
  WindowHeight="250">


...


<Frame Source="FramePage1.xaml" />


...


</Page>

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. Pour obtenir un exemple, consultez Navigation de frame dans une fenêtre, exemple.

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 une application 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 :

<Page 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  WindowTitle="Page that Hosts a Frame"
  WindowWidth="250"
  WindowHeight="250">


...


<Frame Source="FramePage1.xaml" JournalOwnership="OwnsJournal" />


...


</Page>

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

Remarque :

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 :

<Page 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  WindowTitle="Page that Hosts a Frame"
  WindowWidth="250"
  WindowHeight="250">


...


<Frame 
  Source="FramePage1.xaml" 
  JournalOwnership="OwnsJournal" 
  NavigationUIVisibility="Hidden" />


...


</Page>

Hôtes de navigation

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.

<!-- Person.xaml -->
<TextBlock xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation">
  <TextBlock FontWeight="Bold">Name:</TextBlock>
  <TextBlock>Nancy Davolio</TextBlock>
  <LineBreak />
  <TextBlock FontWeight="Bold">Favorite Color:</TextBlock>
  <TextBlock>Yellow</TextBlock>
</TextBlock>

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 XAML libre à partir des éléments suivants :

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

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

  • Le disque local.

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

Remarque :

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

Une limitation en ce qui concerne les 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 XAML libre. Pour plus d'informations, consultez Sécurité de confiance partielle de Windows Presentation Foundation.

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.

<Frame Source="https://www.microsoft.com/default.aspx" />

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

Frame assure une navigation mixte XAML/HTML. Frame prend également en charge l'interopérabilité entre des pages HTML hébergées et des applications WPF hôtes. Aucun mécanisme ne permet spécifiquement d'activer des fonctions de script implémentées par la page HTML pour appeler des méthodes de code managé implémentées par l'application WPF hôte. De la même manière, les applications WPF ne possèdent pas de méthode pour appeler des fonctions de script dans des pages HTML hébergées. Si vous avez besoin de cette fonction, vous pouvez utiliser à la place le contrôle WebBrowser qui prend en charge l'hébergement de documents HTML, la navigation et, bien évidemment, l'interopérabilité code managé/script. Pour plus d'informations sur le contrôle WebBrowser, consultez WebBrowser. Pour obtenir un exemple qui illustre les nombreuses fonctionnalités prises en charge par WebBrowser, consultez Contrôle WebBrowser, exemple.

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

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 substituer 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, qui bénéficie 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 l'exemple complet, consultez Navigation vers un objet personnalisé, exemple.

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

Sécurité

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é de Windows Presentation Foundation et Sécurité de confiance partielle de Windows Presentation Foundation.

Voir aussi

Tâches

Mémoriser un seul ensemble d'états pour plusieurs instances d'une page

Mémoriser plusieurs ensembles d'états par instance de page

Mémoriser un seul élément d'état pour plusieurs instances d'une page

Assistant, exemple

Interface utilisateur NavigationWindow personnalisée, exemple

Navigation de frame dans une fenêtre, exemple

Cookies d'application, exemple

Concepts

Vue d'ensemble de la gestion d'applications

URI à en-tête pack dans Windows Presentation Foundation

Vue d'ensemble des applications Windows Presentation Foundation hébergées par Windows Media Center

Vue d'ensemble de la navigation structurée

Déploiement d'une application WPF (WPF)

Référence

SetCookie

GetCookie

Historique des modifications

Date

Historique

Raison

Juillet 2008

Ajout de la section Navigation vers des fichiers HTML à l'aide du contrôle WebBrowser.

Modifications de fonctionnalités dans le SP1.