Partager via

Afficher plusieurs vues d’une application

  • Article

Mode filaire illustrant une application avec plusieurs fenêtres

Aidez les utilisateurs à accroître leur productivité en leur permettant d’afficher des parties indépendantes de votre application dans des fenêtres distinctes. Lorsque vous créez plusieurs fenêtres pour une application, la barre des tâches répertorie chaque fenêtre séparément. Les utilisateurs peuvent déplacer, redimensionner, afficher et masquer les fenêtres d’application indépendamment et basculer entre les fenêtres d’application comme s’ils étaient des applications distinctes.

API importantes : espace de noms Windows.UI.ViewManagement, espace de noms Windows.UI.WindowManagement

Quand une application doit-elle utiliser plusieurs vues ?

Il existe de nombreux scénarios qui peuvent bénéficier de plusieurs vues. Voici quelques exemples :

  • Une application de messagerie qui permet aux utilisateurs d’afficher une liste des messages reçus tout en rédigeant un e-mail
  • Une application de carnet d’adresses qui permet aux utilisateurs de comparer les informations de contact de plusieurs personnes côte à côte
  • Une application de lecteur de musique qui permet aux utilisateurs de voir ce qui est en cours de lecture tout en naviguant dans une liste d’autres morceaux disponibles
  • Une application de prise de notes qui permet aux utilisateurs de copier des informations à partir d’une page de notes sur une autre
  • Une application de lecture qui permet aux utilisateurs d’ouvrir plusieurs articles à lire plus tard, après avoir pu accéder à tous les gros titres de l'actualité

Chaque disposition d'application est unique, mais nous vous recommandons d'inclure un bouton « nouvelle fenêtre » dans un emplacement prévisible, comme le coin supérieur droit du contenu, qui pourra être ouvert dans une nouvelle fenêtre. Envisagez également d’inclure une option de menu contextuel pour « Ouvrir dans une nouvelle fenêtre ».

Pour créer des instances distinctes de votre application (plutôt que des fenêtres distinctes pour la même instance), consultez Créer une application Windows multi-instance.

Hôtes de fenêtrage

Il existe plusieurs manières d’héberger du contenu Windows dans une application.

  • CoreWindow/ApplicationView

    Une vue d’application est le jumelage 1:1 d’un thread et d’une fenêtre utilisée par l’application pour afficher du contenu. La première vue créée au démarrage de votre application est appelée vue principale. Chaque objet CoreWindow/ApplicationView fonctionne dans son propre thread. L'utilisation de différents threads d’interface utilisateur peut compliquer les applications à plusieurs fenêtres.

    La vue principale de votre application est toujours hébergée dans un objet ApplicationView. Le contenu d’une fenêtre secondaire peut être hébergé dans un objet ApplicationView ou AppWindow.

    Pour savoir comment utiliser ApplicationView afin d'afficher des fenêtres secondaires dans votre application, consultez Utiliser ApplicationView.

  • AppWindow

    AppWindow simplifie la création d’applications Windows multi-fenêtres, car elle fonctionne sur le même thread d’interface utilisateur que celui à partir duquel il est créé.

    La classe AppWindow et les autres API de l’espace de noms WindowManagement sont disponibles à partir de Windows 10, version 1903 (SDK 18362). Si votre application cible des versions antérieures de Windows 10, vous devez utiliser ApplicationView pour créer des fenêtres secondaires.

    Pour savoir comment utiliser AppWindow afin d'afficher des fenêtres secondaires dans votre application, consultez Utiliser AppWindow.

    Remarque

    AppWindow est actuellement disponible en préversion. Dès lors, vous pouvez soumettre des applications utilisant AppWindow sur le Microsoft Store, mais certains composants de plateforme et d'infrastructure peuvent ne pas fonctionner avec AppWindow (voir Limitations).

  • DesktopWindowXamlSource (XAML Islands)

    Le contenu XAML UWP d'une application Win32 (utilisant HWND), également appelé XAML Islands, est hébergé dans un objet DesktopWindowXamlSource.

    Pour plus d’informations sur XAML Islands, consultez Utiliser l'API d’hébergement XAML UWP dans une application de bureau.

Portabilité du code entre les hôtes de fenêtrage

Lorsque le contenu XAML s'affiche dans un objet CoreWindow, il est toujours associé à un objet ApplicationView et XAML Window. Vous pouvez utiliser les API de ces classes pour récupérer des informations telles que les limites de fenêtre. Pour récupérer une instance de ces classes, utilisez la méthode statique CoreWindow.GetForCurrentThread, la méthode ApplicationView.GetForCurrentView ou la propriété Window.Current. En outre, de nombreuses classes utilisent le modèle GetForCurrentView pour récupérer une instance de classe, par exemple DisplayInformation.GetForCurrentView.

Ces API fonctionnent car il n’existe qu’une seule arborescence de contenu XAML pour un CoreWindow/ApplicationView. Le code XAML connaît donc le contexte dans lequel il est hébergé est celui de CoreWindow/ApplicationView.

Lorsque le contenu XAML s’exécute à l’intérieur d’un objet AppWindow ou DesktopWindowXamlSource, plusieurs arborescences de contenu XAML peuvent s’exécuter simultanément sur le même thread. Dans ce cas, ces API ne fournissent pas les informations appropriées, car le contenu n’est plus en cours d’exécution dans coreWindow/ApplicationView (et fenêtre XAML).

Pour vous assurer du bon fonctionnement de votre code dans tous les hôtes de fenêtrage, vous devez remplacer les API reposant sur les objets CoreWindow, ApplicationView, et Window par les nouvelles API obtenant leur contexte à partir de la classe XamlRoot. La classe XamlRoot représente une arborescence de contenu XAML et des informations sur le contexte dans lequel il est hébergé, qu’il s’agisse d’un CoreWindow, d’AppWindow ou de DesktopWindowXamlSource. Cette couche d’abstraction vous permet d’écrire le même code, quel que soit l’hôte de fenêtrage dans lequel le XAML s’exécute.

Ce tableau montre du code qui ne fonctionne pas correctement dans les hôtes de fenêtrage et le code portable de remplacement, ainsi que plusieurs API que vous n'êtes pas tenu de modifier.

Si vous avez utilisé... Remplacez par...
CoreWindow.GetForCurrentThread().Bounds uiElement.XamlRoot.Size
CoreWindow.GetForCurrentThread().SizeChanged uiElement.XamlRoot.Changed
CoreWindow.Visible uiElement.XamlRoot.IsHostVisible
CoreWindow.VisibilityChanged uiElement.XamlRoot.Changed
CoreWindow.GetForCurrentThread().GetKeyState Inchangé. Pris en charge dans AppWindow et DesktopWindowXamlSource.
CoreWindow.GetForCurrentThread().GetAsyncKeyState Inchangé. Pris en charge dans AppWindow et DesktopWindowXamlSource.
Window.Current Retourne l’objet XAML Window principal qui est étroitement lié à l'objet CoreWindow actuel. Consultez la remarque en fin de tableau.
Window.Current.Bounds uiElement.XamlRoot.Size
Window.Current.Content UIElement root = uiElement.XamlRoot.Content
Window.Current.Compositor Inchangé. Pris en charge dans AppWindow et DesktopWindowXamlSource.
VisualTreeHelper.FindElementsInHostCoordinates
Même si le paramètre UIElement est facultatif, la méthode lève une exception si aucun UIElement n’est fourni quand il est hébergé sur un îlot.		 Spécifiez uiElement.XamlRoot comme un UIElement au lieu de le laisser vide.
VisualTreeHelper.GetOpenPopups
Dans les applications XAML Islands, cela génère une erreur. Dans les applications AppWindow, cela renvoie les fenêtres contextuelles ouvertes dans la fenêtre principale.		 VisualTreeHelper.GetOpenPopupsForXamlRoot(uiElement.XamlRoot)
FocusManager.GetFocusedElement FocusManager.GetFocusedElement(uiElement.XamlRoot)
contentDialog.ShowAsync() contentDialog.XamlRoot = uiElement.XamlRoot;
contentDialog.ShowAsync();
menuFlyout.ShowAt(null, new Point(10, 10)); menuFlyout.XamlRoot = uiElement.XamlRoot;
menuFlyout.ShowAt(null, new Point(10, 10));

Remarque

Le contenu XAML d'un objet DesktopWindowXamlSource présente un objet CoreWindow/Window sur le thread, mais il est toujours invisible et a une taille de 1x1. Il est toujours accessible à l’application, mais ne retourne pas de limites ou de visibilité significatives.

Le contenu XAML d'un objet AppWindow présente toujours un objet CoreWindow sur le même thread. Si vous appelez une API GetForCurrentView ou GetForCurrentThread, cette API renvoie un objet qui reflète l’état de CoreWindow sur le thread, mais pas les objets AppWindows susceptibles de s’exécuter sur ce thread.

Pratiques conseillées et déconseillées

  • Fournissez un point d’entrée clair à la vue secondaire en utilisant le glyphe « ouvrir une nouvelle fenêtre ».
  • Communiquez l’objectif de la vue secondaire aux utilisateurs.
  • Assurez-vous que votre application est totalement fonctionnelle dans une vue unique et que les utilisateurs ouvriront une vue secondaire uniquement pour des raisons pratiques.
  • N’utilisez pas la vue secondaire pour fournir des notifications ou d'autres éléments visuels temporaires.