Animations dans une table de montage pour les états visuels

Animations dans une table de montage séquentiel pour les états visuels (XAML)

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Les états visuels sont une technique par laquelle les modifications apportées à l’état d’un contrôle changent l’interface utilisateur en chargeant des modèles de contrôle XAML pour l’état actuel. Le modèle d’état visuel indique à l’utilisateur l’état de l’interface utilisateur et assure la séparation, entre la conception et la logique, utilisée par les contrôles XAML. Pour modifier les propriétés d’un état visuel, vous devez définir des animations de table de montage séquentiel dans XAML. Les animations pour les états visuels utilisent la même syntaxe XAML que les animations de table de montage séquentiel. Cependant, vous devez tenir compte d’un certain nombre de recommandations pour définir correctement les animations afin qu’elles conviennent à un état visuel. Les animations pour les états visuels doivent être instantanées (durée nulle) ou très rapides, en durant moins d’une seconde. Il est également important de concevoir les animations utilisées pour les états visuels de sorte que l’état d’origine d’un contrôle soit rétabli quand cet état ne s’applique plus.

Feuille de route : comment cette rubrique s’articule-t-elle par rapport aux autres ? Voir :

Animations de durée nulle

Chaque fois que vous le pouvez, utilisez des animations de durée nulle pour appliquer des changements de propriété à un état visuel. Une animation de durée nulle est une animation indépendante et, par conséquent, a un impact minime sur les performances du thread d’interface utilisateur. Cela affecte la réactivité du contrôle et de l’application qui l’utilise.

Il peut arriver qu’une animation de l’état visuel nécessite une animation de type TranslateTransform qui n’aura pas un aspect attrayant avec une durée nulle. Mais faites en sorte que la durée de l’animation soit courte (pas plus d’une seconde), car les utilisateurs ne peuvent pas interagir facilement avec des éléments qui bougent. Pour une durée non nulle, l’animation ne peut pas être autre chose qu’une animation dépendante, par conséquent chaque propriété que vous animez devient un facteur important. Vous pouvez également envisager de concevoir ces types d’état avec une VisualTransition avec une durée, mais en veillant à ce que la durée de l’animation de l’état visuel de destination soit nulle.

Pour plus d’informations sur ce qu’implique une animation dépendante et sur les animations qui sont considérées comme dépendantes, voir la section « Animations dépendantes et indépendantes » de la rubrique Animations dans une table de montage séquentiel.

Création d’états visuels qui restaurent les valeurs d’origine

La propriété FillBehavior apparente d’une animation de table de montage séquentiel est différente du comportement des états visuels si vous les appliquez directement à une propriété d’élément de l’interface utilisateur. Si un état visuel change, tous les changements de propriété appliqués par l’état précédent et ses animations sont annulés, même si le nouvel état visuel n’applique pas de façon spécifique une nouvelle animation à une propriété. (Une animation de table de montage séquentiel qui cible, quant à elle, une propriété de l’interface utilisateur de l’application adopte le comportement HoldEnd ; pour plus d’informations, voir Animations dans une table de montage séquentiel.)

Pour de nombreux changements d’état visuel, vous définissez uniquement un nouvel état visuel vide (qui n’a ni animation, ni valeur Storyboard). La logique du contrôle peut appeler l’état visuel vide afin de désactiver les animations appliquées par les autres états visuels dans le même VisualStateGroup. Par exemple, de nombreux modèles de contrôle ont un état nommé "Normal" dans les "CommonStates" VisualStateGroup, qui n’a aucune valeur Storyboard. La logique du contrôle peut accéder à l’état "Normal" pour annuler les autres animations d’état visuel dans le même groupe telles que "PointerOver", "Disabled", etc.

Remarque  Lorsqu’un contrôle accède à un état visuel vide, les propriétés du contrôle utilisent les valeurs du modèle d’origine ou d’autres valeurs par défaut, sauf si le code de l’application change cette valeur au moment de l’exécution ou si la définition XAML d’interface utilisateur a une valeur. Plus précisément, lorsque l’animation de la valeur de propriété est désactivée, la valeur est réévaluée en fonction de la valeur de la propriété de dépendance qui prévaut ; pour plus d’informations sur ce concept, voir Vue d’ensemble des propriétés de dépendance.
 

États visuels pour les interactions de l’utilisateur avec le pointeur

La plupart des contrôles qui définissent les états visuels et qui peuvent être sélectionnés ou invoqués d’une manière ou d’une autre ont un groupe visuel principal nommé "CommonStates". Les états nommés suivants figurent dans "CommonStates" :

  • "Normal"
  • "PointerOver"
  • "Pressed"
  • "Disabled"

"Normal" est l’état du contrôle lorsque l’utilisateur n’a pas appuyé dessus, lorsqu’il n’est pas désactivé et que le pointeur n’est pas sur sa zone de test de positionnement. "PointerOver" et "Pressed" sont en général des états dont la durée est relativement courte et qui sont liés aux actions de l’utilisateur.

"Disabled" est utilisé lorsque la valeur de IsEnabled est false ou que d’autres propriétés telles que IsReadOnly déclarent que le contrôle ne peut pas être utilisé. Ces propriétés sont en général définies par le code de l’application. La logique de l’application peut désactiver des contrôles pour des contextes dans lesquels l’utilisateur doit utiliser d’autres contrôles sans pour autant masquer entièrement les contrôles désactivés si c’est ce que vous avez choisi.

Dans la plupart des cas, si vous utilisez un état visuel, vous modifiez une conception existante, soit dans la copie du modèle avec lequel vous avez commencé, soit dans le modèle par défaut de la classe du contrôle que vous utilisez comme classe de base. Vous pouvez vous baser sur ces comportements de conception existants pour indiquer à chacun des états visuels "CommonStates" ce qu’il doit montrer à l’utilisateur. Si vous avez encore des questions concernant la conception pour ces états visuels ou si vous écrivez un modèle qui n’a rien à voir avec les autres modèles existants et souhaitez obtenir de l’aide, voir Recommandations en matière de retour visuel et Réponse à l’interaction utilisateur. Les entrées tactiles et via la souris génèrent des événements de pointeur. Au niveau de l’état visuel, ces modes d’interaction ne sont en général pas différenciés.

Indication du focus visuel

Un des aspects les plus importants qu’un contrôle doit fournir, en termes d’interactivité et d’état, est de permettre à l’utilisateur de savoir quand le contrôle a le focus dans une interface utilisateur. Un contrôle avec le focus est le seul contrôle qui peut accepter des entrées à l’aide du clavier, il est donc important pour l’utilisateur de savoir qu’une zone de texte dans l’interface utilisateur a le focus pour cela. En outre, pour des raisons d’accessibilité, il est important d’identifier le focus même pour des contrôles qui ne nécessitent pas l’entrée de texte via le clavier. Par exemple, les contrôles tels que les boutons doivent prendre en charge un mode d’invocation pour effectuer la même action à l’aide d’une touche du clavier (en général, espace ou Entrée) qu’en cliquant ou en appuyant sur un bouton. En procédant correctement, les utilisateurs peuvent utiliser la touche Tab et d’autres touches pour interagir avec une interface utilisateur sans toucher l’écran ou utiliser la souris. Pour plus d’informations à ce sujet, voir Implémentation de l’accessibilité du clavier .

En général, un état visuel utilise un Rectangle, qui n’est d’abord pas visible, en tant qu’indicateur de focus (Opacity="0"). Le Rectangle est un enfant immédiat de la racine du modèle, qui est en général une des classes Panel. Veillez à ce que le Rectangle utilise une propriété Stroke étroite, qui couvre uniquement les zones d’espacement autour du contenu du contrôle lorsqu’il a le focus. Sinon le contrôle risque de masquer du contenu important. Dans une conception d’état visuel type, les états pour cela font partie d’un VisualStateGroup nommé "FocusStates" dans lequel deux états sont nommés "Focused" et "Unfocused".

Dans le groupe "FocusStates" VisualStateGroup, vous devez définir un état visuel vide séparé "PointerFocused". L’indicateur du focus ne doit pas apparaître s’il s’agit d’un pointeur qui dirige le focus vers un contrôle. L’indicateur de focus est destiné à montrer un focus spécifique à un élément que choisit un utilisateur à l’aide de la touche Tab, ou un focus placé par programme lorsque la page de l’application est chargée.

Autres états visuels

  • Les contrôles tels que CheckBox définissent un VisualStateGroup appelé "CheckStates". Dans le modèle par défaut, les états nommés dans ce groupe sont : "Checked", "Unchecked" et "Indeterminate".
  • Les contrôles qui prennent en charge une opération de glisser-déplacer ont un groupe nommé "DragStates" contenant plusieurs états. Vous verrez ces états dans le code XAML de départ si vous modifiez une copie du modèle de contrôle GridViewItem, par exemple.
  • Les contrôles qui prennent en charge la sélection d’éléments disposent de plusieurs états de sélection se trouvant dans les modèles de leurs types d’élément. Les noms des groupes et des états varient selon le contrôle. Vous pouvez les voir si vous modifiez une copie du modèle du contrôle.
  • Certains des projets Microsoft Visual Studio Windows 8 pour les applications définissent des états visuels pour les états d’affichage de la zone d’affichage. Ce n’est plus le cas des modèles Windows 8.1.

Exemple XAML

Voici un exemple XAML d’un ensemble type d’états visuels dans un VisualStateGroup appelé "CommonStates". Il est tiré directement des modèles Windows Runtime par défaut pour les contrôles et autres éléments d’interface utilisateur. Vous pouvez modifier une copie du code XAML de modèle par défaut si vous souhaitez personnaliser certains des boutons AppBar dans votre application. Comme illustré ici, le code XAML diffère légèrement du modèle complet, avec des points de suspension ... affichés, car vous n’avez pas besoin de voir le fichier entier ou chaque état visuel pour comprendre les principes de base.


<Style x:Key="BackButtonStyle" TargetType="Button">
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="Button">
        <Grid x:Name="RootGrid">
...
          <VisualStateManager.VisualStateGroups>
            <VisualStateGroup x:Name="CommonStates">
              <VisualState x:Name="Normal"/>
...
              <VisualState x:Name="Disabled">
                <Storyboard>
                  <ObjectAnimationUsingKeyFrames 
                    Storyboard.TargetName="RootGrid"
                    Storyboard.TargetProperty="Visibility"
                  >
                    <DiscreteObjectKeyFrame Value="Collapsed" KeyTime="0"/>
                  </ObjectAnimationUsingKeyFrames>
                </Storyboard>
              </VisualState>
            </VisualStateGroup>
...
          </VisualStateManager.VisualStateGroups>
        </Grid>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>

  • L’état "Disabled" applique une animation de table de montage séquentiel à la propriété Visibility. La propriété Visibility requiert une énumération, par conséquent pour l’animer, vous devez utiliser un DiscreteObjectKeyFrame pour définir la propriété Value avec une constante particulière de l’énumération Visibility. Appliquer un changement à la propriété Visibility d’un élément de composition, ou quelque fois le contrôle entier, est très courant dans les définitions d’état visuel.
  • Notez que l’état "Normal" est vide. La logique du contrôle peut charger cet état pour annuler l’état visuel nommé "Disabled" et restaurer la valeur définie par le modèle de la propriété Visibility, qui est Visible par défaut.

Logique de contrôle pour utiliser les états visuels

La logique de contrôle type utilise divers éléments d’entrée et propriétés d’état pour déterminer quel état visuel des différents groupes d’états visuels doit être actif dans un contrôle au lorsque celui-ci est activé.

  • Les états visuels de pointeur (par exemple "PointerOver" et "Pressed") peuvent être changés en gérant les événements d’entrée (les événements PointerEntered et PointerExited). En général, les contrôles traitent ces événements en substituant les gestionnaires intégrés OnPointerEntered et OnPointerExited.
  • "Disabled" peut être appelé par IsEnabledChanged ou des gestionnaires pour apporter des changements à d’autres propriétés de contrôle comme IsReadOnly.
  • Les états visuels de focus peuvent être changés en gérant les événements GotFocus et LostFocus. En général les contrôles traitent ces événements en remplaçant les gestionnaires OnGotFocus et OnLostFocus. Pour OnGotFocus, la logique de contrôle doit vérifier le FocusState pour déterminer si le pointeur a entraîné le changement de focus, et si c’est le cas, elle doit utiliser l’état "PointerFocused" au lieu de "Focused".

VisualTransition

En plus de définir les divers états visuels nommés, un VisualStateGroup peut également comporter une collection d’éléments VisualTransition. Une classe VisualTransition définit le comportement d’une animation qui s’exécute lorsqu’un changement d’état se produit (lorsque la méthode GoToState est appelée). Vous verrez une transition visuelle lorsque l’ancien et le nouvel état ont des valeurs de propriété différentes, et qu’une VisualTransition référence ces deux états nommés respectivement avec la valeur From et la valeur To.

La durée d’une VisualTransition n’est en général pas nulle, car le but d’une transition visuelle est de montrer un changement lorsque les états visuels changent.

De manière générale, il y a deux manières de définir une VisualTransition : en utilisant un Storyboard spécifique qui définit une ou plusieurs propriétés pour lesquelles vous appliquez une animation de table de montage séquentiel chronométrée ou en faisant appel au comportement GeneratedDuration.

Un Storyboard spécifique utilise en général les techniques décrites dans cette rubrique et la rubrique Animations dans une table de montage séquentiel, sauf qu’il est préférable de ne pas utiliser d’animations à durée nulle dans ce Storyboard . Les propriétés que vous animez dans la transition visuelle ne doivent pas obligatoirement changer entre les états visuels intervenant dans la transition.

Le comportement GeneratedDuration doit simplement avoir une propriété GeneratedDuration avec une valeur non nulle. Puis, le système d’état visuel détermine quelles propriétés changent de valeur entre l’ancien et le nouvel état et génère une animation interpolée entre les valeurs changées qui s’exécute pour la durée définie. Le comportement GeneratedDuration fonctionne uniquement pour les valeurs qui peuvent être interpolées par l’animation : les valeurs Double, Point ou Color.

Pour une VisualTransition vous définissez les états visuels entre lesquels la VisualTransition doit se produire. From référence l’ancien état et To référence le nouvel état. Si vous avez une valeur pour From mais pas pour To ou inversement, la valeur non définie est interprétée comme faisant référence à un autre état qui est également dans le même groupe d’états visuels. Une VisualTransition sans valeur pour From ni To est inactive.

Pour utiliser un comportement d’interpolation différent du comportement par défaut d’une interpolation linéaire, définissez une valeur pour GeneratedEasingFunction. Pour obtenir une liste des fonctions d’accélération que vous pouvez utiliser et les formules mathématiques de fonction de temps représentées par chacune d’elles, voir Animations par images clés et animations de fonctions d’accélération

Procédez avec précaution avec le comportement GeneratedDuration. Étant donné qu’il ne s’agit pas d’une animation à durée nulle par définition, vous risquez de créer accidentellement une animation dépendante sur des propriétés qui changent et ainsi nuire aux performances de votre contrôle ou application.

Les animations VisualState s’exécutent chaque fois qu’un état est entré même lorsque le contrôle apparaît. Ce n’est pas le cas des animations VisualTransition. Pour celles-ci, il n’y a aucune transition dans le premier état chargé même s’il y a une transition qui spécifie le premier état comme état To.

Modification des copies de modèle

Des outils tels que Visual Studio permettent de remodéliser facilement un contrôle à partir d’une copie d’un segment du XAML de modèle Windows Runtime par défaut, que l’on place à un endroit où l’application et le projet peuvent l’utiliser et la modifier. Les états visuels d’un contrôle sont également inclus dans ce modèle dans un nœud XAML VisualStateManager.VisualStateGroups directement sous l’élément racine du contenu du modèle, dans le Style Setter Template principal. Lorsque vous travaillez avec une copie du modèle, veillez à reproduire tous les états visuels nommés et les groupes d’états visuels que le modèle contenait au début. Si vous ne le faites pas, le contrôle risque de ne pas disposer d’états visuels importants qui informent l’utilisateur des interactions avec l’interface utilisateur. La logique du contrôle tente alors d’appeler GoToState pour accéder aux états nommés attendus qui n’existent pas dans votre modèle XAML personnalisé et le comportement VisualStateManager maintient le contrôle dans le dernier état visuel qui s’est chargé correctement. Par exemple, le contrôle peut être maintenu dans un état "PointerOver" même lorsque le pointeur n’est plus sur le contrôle, si vous n’avez pas fourni l’état "Normal" qui est en général appelé lorsque le pointeur quitte le contrôle.

Pour plus d’informations sur la modification des modèles de contrôles, voir Démarrage rapide : modèles de contrôles.

Ne pas utiliser d’états visuels de différents groupes pour animer la même propriété

La plupart des modèles d’états visuels disposent de plusieurs groupes d’états visuels, où chaque groupe est chargé de représenter l’état d’un ensemble de conditions qui sont exclusives dans ce groupe. Par exemple, un contrôle peut avoir un groupe qui répond aux événements de pointeur, un ensemble qui répond aux éléments sélectionnés au clavier et un état pour l’entrée de texte. À ce titre, un contrôle utilise vraiment plusieurs états à la fois. Si des états de différents groupes modifient la même propriété en tant qu’action d’état visuel, la valeur utilisée devient indéterminée, car elle dépend maintenant du dernier état entré. À ne pas faire. Il peut être nécessaire d’introduire des éléments étroitement liés dans votre modèle de contrôle pour vous assurer que différents groupes d’états visuels utilisent différents éléments quand ils animent des propriétés qui affectent l’aspect visuel du contrôle.

Utilisation de la bibliothèque d’animations dans les états visuels

La bibliothèque d’animations pour Windows Runtime comprend plusieurs animations thématiques. Les animations thématiques sont des animations appliquées à une ou plusieurs propriétés de types d’interface utilisateur XAML Windows Runtime prédéfinis. Certains contrôles XAML Windows Runtime incluent des animations thématiques dans leurs états visuels par défaut. Ces animations peuvent se trouver à deux emplacements :

  • comme l’une des animations dans l’objet VisualState.Storyboard pour un ou plusieurs états visuels du contrôle. À cet emplacement, l’animation thématique s’exécute quand cet état visuel est utilisé (quand la logique du contrôle appelle GoToState faisant référence à cet état) ;
  • comme l’une des animations dans l’objet VisualTransition.Storyboard, dans VisualStateGroup.Transitions. À cet emplacement, l’animation thématique s’exécute quand le gestionnaire d’état visuel exécute la transition entre les deux états nommé concernés.

Si vous utilisez la technique ordinaire qui consiste à démarrer avec une copie XAML du modèle de contrôle par défaut que vous avez obtenue avec Modifier le modèle/Modifier une copie dans Microsoft Visual Studio, des animations thématiques peuvent figurer dans votre copie de départ. En général, vous ne devez pas supprimer les animations thématiques du modèle d’un contrôle. Elles sont là dans un but spécifique, non seulement pour fournir l’apparence de ce contrôle XAML, mais aussi pour renforcer une expérience utilisateur globale Windows.

Pour utiliser une animation thématique, vous devez cibler cette animation sur un composant donné dans le modèle. Pour cela, vous devez définir l’attribut TargetName de l’animation thématique à l’aide d’une chaîne qui est le x:Name de l’un des composants de modèle définis ailleurs dans le modèle (il s’agit des composants qui définissent le modèle de départ). Les animations thématiques ciblent des propriétés spécifiques de manière inhérente et ciblent parfois plusieurs propriétés associées en arrière-plan. Comme on ne peut pas identifier immédiatement les propriétés ciblées par une animation thématique, il est également difficile de savoir quels composants il faut cibler à l’aide de TargetName pour que la cible et les propriétés animées soient alignées.

Important  N’utilisez pas Storyboard.TargetName ou Storyboard.TargetProperty quand vous ciblez une animation thématique. Ce modèle de ciblage est en conflit avec l’attribut non joint TargetName et avec la nature inhérente du ciblage de propriété par les animations thématiques.
 

Quand les styles ou modèles par défaut d’un contrôle utilisent une animation thématique particulière, elle est mentionnée dans les rubriques « Animation ... » qui documentent comment et quand utiliser les animations de la bibliothèque spécifiques. Par exemple, si vous consultez Animation des actions de pointeur, vous verrez une section intitulée « Comportement des animations de pointeur dans les contrôles Windows Runtime par défaut » où il est mentionné que ListViewItem et GridViewItem incluent une classe PointerDownThemeAnimation dans l’un de leurs états visuels du modèle par défaut. Cela peut également être noté dans la documentation sur les styles et les modèles des contrôles. Par exemple, Styles et modèles de contrôle ListViewItem montre exactement où existe l’objet PointerDownThemeAnimation dans la section « Style par défaut » qui fournit le XAML complet.

Les animations thématiques ont généralement une durée non nulle, mais courte (souvent moins de deux secondes). Elles sont soigneusement construites pour cibler des propriétés qui ne génèrent pas d’animations dépendantes.

La plupart des animations thématiques n’ont pas de propriétés autres que TargetName et celles qu’elles héritent de Timeline. Certaines animations thématiques ont toutefois des propriétés supplémentaires. Par exemple, PopInThemeAnimation a une propriété FromHorizontalOffset qui modifie la position où débute l’animation. Soyez prudent lors de la modification de ces propriétés, car elles utilisent des valeurs par défaut qui présentent une expérience utilisateur Windows cohérente. Une modification radicale du comportement peut être aussi néfaste que la suppression de l’animation thématique entière.

Comme mentionné plus haut, certains contrôles ont des animations thématiques présentes par défaut dans leurs états visuels ou transitions visuelles. Mais dans certains cas, les propriétés d’une animation de la bibliothèque utilisées par un contrôle pour ses états visuels ou son style peuvent être affectées d’un style sans avoir à remplacer entièrement le modèle de contrôle. Vous devez pour cela changer la valeur de propriété TemplateSettings sur le contrôle. Voici une liste de contrôles pour lesquels vous pouvez modifier les animations thématiques en dehors des modèles, en faisant référence à la propriété qui le prend en charge :

Il existe un autre type d’animation dans la bibliothèque d’animations appelé transition thématique. Ces animations s’utilisent pour les propriétés *Transitions sur des contrôles spécifiques, ou éventuellement pour la propriété UIElement.Transitions. Ces propriétés ne sont pas dans les états visuels, mais les transitions thématiques sont en général pertinentes pour l’application de styles aux contrôles car vous définissez généralement les propriétés *Transitions dans le Style par défaut (clé implicite) pour un Control, ou éventuellement pour d’autres éléments d’interface utilisateur tels que TextBlock. Certains des TemplateSettings mentionnés plus haut affectent les transitions thématiques. Pour plus d’informations sur la façon d’utiliser les transitions thématiques, voir Animation de votre interface utilisateur ou Démarrage rapide : animation de votre interface utilisateur avec des animations de la bibliothèque.

États visuels pour des scénarios autres que les modèles de contrôles

L’utilisation d’états visuels pour définir les états d’interface utilisateur actifs n’est pas limitée à la modélisation des contrôles. Vous pouvez utiliser des états visuels chaque fois que vous voulez appliquer des changements de propriété qui doivent uniquement s’appliquer au cours d’une condition détectable. Par exemple, vous pouvez utiliser des états visuels pour les pages de votre application afin de détecter les états d’application ou de fenêtre et de changer les propriétés de disposition en conséquence. Les états visuels pour les scénarios sans modèle ont besoin de code pour détecter les changements d’état et invoquer l’état visuel correct sur l’élément de l’interface utilisateur qui utilise les états. Cela peut nécessiter de gérer des événements qui font partie du modèle d’application, tels que les événements sur Window, des événements de périphérique système qui détectent des modifications de l’orientation de l’affichage ou de la résolution, ou des gestionnaires d’activation sur Application. Certains de ces concepts empiètent sur le modèle d’application et la façon dont votre application peut assurer le suivi des états d’affichage ; pour plus d’informations, voir Démarrage rapide : conception d’applications pour différentes tailles de fenêtres.

Rubriques associées

Réponse à l’interaction utilisateur
Animations dans une table de montage séquentiel
Feuille de route pour la création d’applications en C#, C++ ou VB
Vue d’ensemble des propriétés de dépendance
Animations par images clés et animations de fonctions d’accélération
Démarrage rapide : modèles de contrôles
VisualStateManager
VisualState
VisualTransition
Storyboard
Storyboard.TargetProperty

 

 

Afficher:
© 2017 Microsoft