Animations dans une table de montage séquentiel

  • Article

Les animations de table de montage séquentiel ne sont pas seulement des animations au sens visuel. Une animation de table de montage séquentiel permet de changer la valeur d’une propriété de dépendance en tant que fonction de temps. Vous pouvez avoir notamment besoin d’une animation de table de montage séquentiel qui ne provient pas de la bibliothèque des animations pour définir l’état visuel d’un contrôle dans un modèle de contrôle ou une définition de page.

Différences entre Silverlight et WPF

Si vous connaissez déjà Microsoft Silverlight ou Windows Presentation Foundation (WPF), lisez cette section. Dans le cas contraire, vous pouvez l’ignorer.

En règle générale, la création d’animations de table de montage séquentiel dans une application du Windows Runtime est similaire à Silverlight ou WPF. Des différences importantes sont cependant à noter :

  • Les animations de table de montage séquentiel ne sont pas le seul moyen d’animer visuellement une interface utilisateur, ni le moyen le plus simple à la disposition des développeurs d’applications pour ce faire. À la place des animations de table de montage séquentiel, il est souvent préférable en matière de conception d’utiliser des animations de thème et de transition. Vous pouvez ainsi créer rapidement des animations d’interface utilisateur recommandées sans avoir besoin de cibler des propriétés d’animation, ce qui peut s’avérer délicat. Pour plus d’informations, consultez Vue d’ensemble des animations.
  • Dans Windows Runtime, de nombreux contrôles XAML comportent des animations de thème et de transition inhérentes à leur comportement. Dans la plupart des cas, les contrôles WPF et Silverlight n’avaient pas de comportement d’animation par défaut.
  • Les applications personnalisées que vous créez ne peuvent pas toutes s’exécuter par défaut dans une application Windows Runtime, si le système d’animations détermine qu’elles peuvent nuire aux performances de votre interface utilisateur. Les animations pour lesquelles le système détermine qu’il pourrait y avoir un impact sur les performances portent le nom d’animations dépendantes. Elles sont dépendantes car le minutage de votre animation opère directement sur le thread d’interface utilisateur, qui est également celui sur lequel l’entrée utilisateur active et d’autres mises à jour tentent d’appliquer les modifications d’interface utilisateur au moment de l’exécution. Une animation dépendante qui consomme d’importantes ressources système sur le thread d’interface utilisateur peut dans certaines situations donner l’impression que l’application a cessé de répondre. Si votre animation entraîne la modification de la disposition ou est susceptible d’avoir une incidence sur les performances du thread d’interface utilisateur, vous devez alors activer l’animation dans votre code de façon explicite pour la voir s’exécuter. C’est là qu’entre en jeu la propriété EnableDependentAnimation sur des classes d’animation spécifiques. Pour plus d’informations, voir Animations dépendantes et indépendantes.
  • Les fonctions d’accélération personnalisées ne sont actuellement pas prises en charge dans Windows Runtime.

Définition d’animations de table de montage séquentiel

Une animation de table de montage séquentiel permet de changer la valeur d’une propriété de dépendance en tant que fonction de temps. La propriété que vous animez n’est pas toujours une propriété qui a une incidence directe sur l’interface utilisateur de votre application. Mais étant donné que XAML sert à la définition de l’interface utilisateur des applications, vous êtes en général amené à animer une propriété d’interface utilisateur. Par exemple, vous pouvez animer l’angle d’un RotateTransform ou la valeur de la couleur de l’arrière-plan d’un bouton.

Vous pouvez être principalement amené à définir une animation de table de montage séquentiel, si vous êtes un créateur de contrôle ou remodélisez un contrôle, afin de définir des états visuels. Pour plus d’informations, voir Animations dans une table de montage séquentiel pour les états visuels.

Que vous définissiez des états visuels ou une animation personnalisée pour une application, les concepts et les API pour les animations de table de montage décrits dans cette rubrique s’appliquent pour la plupart d’entre eux aux deux cas.

Afin d’être animée, la propriété que vous ciblez avec une animation de table de montage séquentiel doit être une propriété de dépendance. Une propriété de dépendance est une fonctionnalité clé de l’implémentation Windows Runtime XAML. Les propriétés accessibles en écriture de la plupart des éléments d’interface utilisateur sont en général implémentées en tant que propriétés de dépendance. Vous pouvez ainsi les animer, appliquer des valeurs liées aux données ou appliquer un Style et cibler la propriété avec un Setter. Pour plus d’informations sur le fonctionnement des propriétés de dépendance, voir Vue d’ensemble des propriétés de dépendance.

La plupart du temps, vous définissez une animation de table de montage séquentiel en écrivant du code XAML. Si vous utilisez un outil tel que Microsoft Visual Studio, le balisage XAML sera produit automatiquement. Il est également possible de définir une animation de table de montage séquentiel avec du code, mais cela est moins courant.

Examinons un exemple simple. Dans cet exemple XAML, la propriété Opacity est animée sur un objet Rectangle particulier.

<Page ...>
  <Page.Resources>
    <!-- Storyboard resource: Animates a rectangle's opacity. -->
    <Storyboard x:Name="myStoryboard">
      <DoubleAnimation
        Storyboard.TargetName="MyAnimatedRectangle"
        Storyboard.TargetProperty="Opacity"
        From="1.0" To="0.0" Duration="0:0:1"/>
    </Storyboard>
  </Page.Resources>

  <!--Page root element, UI definition-->
  <Grid>
    <Rectangle x:Name="MyAnimatedRectangle"
      Width="300" Height="200" Fill="Blue"/>
  </Grid>
</Page>

Identification de l’objet à animer

Dans l’exemple précédent, la table de montage séquentiel animait la propriété Opacity d’un Rectangle. La déclaration des animations ne s’effectue pas sur l’objet lui-même. Au lieu de cela, vous effectuez cette opération dans la définition d’animation d’un storyboard. Les storyboards sont généralement définis en XAML qui ne se trouvent pas à proximité immédiate de la définition d’interface utilisateur XAML de l’objet à animer. En fait, elles sont en général configurées comme une ressource XAML.

Pour connecter une animation à une cible, vous devez référencer la cible avec son nom de programmation. Vous devez toujours appliquer l’attribut x:Name dans la définition de l’interface utilisateur XAML pour nommer l’objet que vous voulez animer. Vous devez ensuite cibler l’objet à animer en définissant Storyboard.TargetName dans la définition de l’animation. Pour la valeur de Storyboard.TargetName, vous devez utiliser la chaîne de nom de l’objet cible, qui est ce que vous avez défini auparavant et ailleurs avec l’attribut x:Name.

Ciblage de la propriété de dépendance à animer

Vous définissez une valeur pour Storyboard.TargetProperty dans l’animation. Cela détermine quelle propriété spécifique de l’objet ciblé est animée.

Parfois vous devez cibler une propriété qui n’est pas une propriété immédiate de l’objet cible, mais qui est imbriquée plus profondément dans une relation objet-propriété. Vous devez souvent effectuer cette opération pour explorer un ensemble de valeurs d’objet et de propriété contributrices jusqu’à ce que vous puissiez référencer un type de propriété qui peut être animé (Double, Point, Color). Ce concept porte le nom de ciblage indirect et la syntaxe de ciblage d’une propriété de cette manière porte le nom de chemin d’accès de propriété.

Voici un exemple. Un exemple courant de scénario pour une animation de table de montage séquentiel consiste à changer la couleur d’une partie de l’interface utilisateur ou d’un contrôle d’une application afin d’indiquer l’état de ce contrôle. Supposons que vous souhaitiez animer le premier plan d’un TextBlock, afin qu’il passe du rouge au vert. Vous vous attendez à ce qu’une ColorAnimation soit impliquée, et c’est correct. Cependant, aucune des propriétés sur les éléments d’interface utilisateur qui modifient la couleur de l’objet n’est de type Color. Elles sont en fait de type Brush. Par conséquent, pour votre animation, vous devez cibler la propriété Color de la classe SolidColorBrush dont le type est dérivé de Brush. Ce type est en général utilisé pour les propriétés de couleur d’interface utilisateur. Voici ce que cela donne pour la formation d’un chemin d’accès de propriété pour le ciblage d’une propriété de votre animation :

<Storyboard x:Name="myStoryboard">
  <ColorAnimation
    Storyboard.TargetName="tb1"
    Storyboard.TargetProperty="(TextBlock.Foreground).(SolidColorBrush.Color)"
    From="Red" To="Green"/>
</Storyboard>

Voici comment interpréter chacune des parties de la syntaxe :

  • Chaque paire de parenthèses () contient un nom de propriété.
  • Le nom de la propriété comporte un point. Ce point sépare un nom de type et un nom de propriété, par conséquent la propriété que vous identifiez est correcte.
  • Le point au milieu, c’est-à-dire celui qui n’est pas entre parenthèses, est une étape. Pour la syntaxe cela veut dire, prendre la valeur de la première propriété (qui est un objet), aller dans son modèle d’objet et cibler une sous-propriété spécifique de la valeur de la première propriété.

Voici une liste de scénarios de ciblage d’animation dans lesquels vous utiliserez probablement un ciblage de propriété indirect, ainsi que des chaînes de chemin d’accès aux propriétés qui se rapprochent de la syntaxe que vous utiliserez :

Vous remarquerez que certains de ces exemples utilisent des crochets autour des nombres. Il s’agit d’indexeurs. Ils indiquent que le nom de la propriété qui les précède a pour valeur une collection dans laquelle vous voulez un élément (identifié par un index basé sur zéro).

Vous pouvez également animer des propriétés XAML jointes. Veillez à toujours placer le nom de la propriété jointe entre parenthèses, par exemple (Canvas.Left). Pour plus d’informations, voir Animation des propriétés XAML jointes.

Pour plus d’informations sur la façon d’utiliser un chemin d’accès de propriété pour le ciblage indirect de la propriété à animer, voir Syntaxe de Property-path ou Propriété jointe Storyboard.TargetProperty.

Types d’animation

Le système d’animations de Windows Runtime comporte trois types spécifiques auxquels les animations de table de montage séquentiel peuvent s’appliquer :

Il existe également un type d’animation Objet généralisé pour les valeurs de référence d’objet, que nous aborderons plus loin.

Spécification des valeurs animées

Jusqu’à présent, nous vous avons montré comment cibler l’objet et la propriété à animer mais nous ne vous avons pas expliqué ce qu’il arrive à la valeur de la propriété lorsque l’animation est exécutée.

Les types d’animation que nous avons décrits sont parfois appelés animations From/To/By . Cela veut dire que l’animation change au fur et à mesure la valeur d’une propriété en utilisant les informations provenant de sa définition :

  • La valeur commence à la valeur From. Si vous ne spécifiez pas une valeur From, la valeur de départ est la valeur de la propriété animée avant que l’animation s’exécute. Il peut s’agir d’une valeur par défaut, d’une valeur provenant d’un style ou d’un modèle ou d’une valeur appliquée spécifiquement par une définition d’interface utilisateur XAML ou le code de l’application.
  • À la fin de l’animation, la valeur est la valeur To.
  • Ou, pour spécifier une valeur de fin par rapport à la valeur de départ, définissez la propriété By au lieu de la propriété To.
  • Si vous ne spécifiez pas une valeur To ou une valeur By, la valeur de fin est la valeur de la propriété animée avant que l’animation s’exécute. Dans ce cas, il vaut mieux que vous ayez une valeur From, car autrement l’animation ne changera pas la valeur ; ses valeurs de début et de fin étant les mêmes.
  • En général, une animation a au moins une des trois valeurs From, By ou To, mais jamais les trois.

Revenons à l’exemple XAML précédent et examinons de nouveau les valeurs From et To et la valeur Duration. L’exemple anime la propriété Opacity et le type de la propriété Opacity est Double. Par conséquent, l’animation à utiliser ici est DoubleAnimation.

From="1.0" To="0.0" spécifie que lorsque l’animation s’exécute, la propriété Opacity commence à une valeur de 1 et s’anime sur 0. Concernant la signification de ces valeurs Double pour la propriété Opacity, avec cette animation, l’objet sera opaque au début puis deviendra transparent.

...
<Storyboard x:Name="myStoryboard">
  <DoubleAnimation
    Storyboard.TargetName="MyAnimatedRectangle"
    Storyboard.TargetProperty="Opacity"
    From="1.0" To="0.0" Duration="0:0:1"/>
</Storyboard>
...

Duration="0:0:1" spécifie la durée de l’animation, c’est-à-dire la vitesse à laquelle le rectangle disparaît. Une propriété Duration est spécifiée sous la forme hours:minutes:seconds. La durée dans cet exemple est d’une seconde.

Pour plus d’informations sur les valeurs de durée et la syntaxe XAML, consultez Durée.

Notes

Pour l’exemple que nous avons montré, si vous étiez sûr que l’état de départ de l’objet animé est toujours égal à 1, par le biais de la valeur par défaut ou d’un ensemble explicite, vous pouvez omettre la valeur From , l’animation utiliserait la valeur de départ implicite et le résultat serait le même.

From/To/By sont des propriétés Nullable.

Nous avons mentionné précédemment que vous pouvez omettre From, To ou By et par conséquent utiliser les valeurs non animées actuelles en remplacement d’une valeur manquante. Les propriétés From, To ou By d’une animation ne sont pas du type que vous pouvez deviner. Par exemple, le type de la propriété DoubleAnimation.To n’est pas Double. Au lieu de cela, il s’agit d’une valeur Nullable pour Double. Et sa valeur par défaut est null et non 0. Cette valeur Null est la façon dont le système d’animation distingue que vous n’avez pas spécifiquement défini de valeur pour une propriété From, To ou By . Le type des extensions des composants Visual C++ (C++/CX) n’est pas Nullable, par conséquent elles utilisent IReference à la place.

Autres propriétés d’une animation

Les propriétés suivantes décrites dans cette section sont toutes facultatives du fait qu’elles ont des valeurs par défaut qui conviennent à la plupart des animations.

AutoReverse

Si vous ne spécifiez pas AutoReverse ou RepeatBehavior sur une animation, cette animation s’exécute une seule fois et s’exécute pendant la durée spécifiée en tant que Durée.

La propriété AutoReverse spécifie si une chronologie est lue à l’envers une fois qu’elle a atteint la fin de sa durée. Si vous l’avez définie sur true, l’animation repart en arrière une fois qu’elle est arrivée au terme de sa durée déclarée comme l’indique sa propriété Duration. Pour cela, elle remplace sa valeur de fin (To) par sa valeur de début (From). Cela signifie que la durée de l’animation est le double de la valeur de sa propriété Duration.

RepeatBehavior

La propriété RepeatBehavior spécifie le nombre de fois qu’un chronologie est lu ou une durée plus élevée pendant laquelle le chronologie doit se répéter. Par défaut, le nombre d’itérations d’une chronologie est « 1x », ce qui signifie qu’elle s’exécute une fois selon la valeur de sa propriété Duration et qu’elle ne se répète pas.

Vous pouvez entraîner l’exécution de plusieurs itérations par l’animation. Par exemple, la valeur « 3x » entraîne l’exécution de l’animation trois fois. Vous pouvez également spécifier une durée différente pour RepeatBehavior. Cette valeur de Duration ne doit pas être plus longue que la valeur de Duration de l’animation elle-même pour être effective. Par exemple, si vous spécifiez une propriété RepeatBehavior avec la valeur « 0:0:10 », pour une animation dont la propriété Duration a la valeur « 0:0:2 », cette animation se répète cinq fois. Si ces valeurs ne sont pas divisibles équitablement, l’animation est tronquée au moment où la valeur de RepeatBehavior est atteinte, ce qui peut être en plein milieu. Enfin, vous pouvez spécifier la valeur spéciale « Forever », qui entraîne l’exécution infinie de l’animation jusqu’à ce qu’elle soit délibérément arrêtée.

Pour plus d’informations sur les valeurs RepeatBehavior et la syntaxe XAML, consultez RepeatBehavior.

FillBehavior= « Stop »

Par défaut, lorsqu’une animation se termine, l’animation conserve la valeur finale de To ou modifiée de By pour sa propriété de durée, même une fois celle-ci dépassée. Cependant, si vous définissez la valeur de la propriété FillBehavior sur FillBehavior.Stop, la valeur de la valeur animée avant que l’animation ait été appliquée est rétablie, ou plus précisément, la valeur effective déterminée par le système de propriétés de dépendance (pour plus d’informations sur cette distinction, voir Vue d’ensemble des propriétés de dépendance).

BeginTime

Par défaut, la valeur de la propriété BeginTime d’une animation est « 0:0:0 ». Par conséquent, l’animation commence dès que son Storyboard (table de montage séquentiel) s’exécute. Vous pouvez changer cette valeur si le Storyboard contient plusieurs animations et si vous voulez échelonner le démarrage des autres animations par rapport à une animation initiale, ou pour créer délibérément un léger retard.

SpeedRatio

Si un Storyboard contient plusieurs animations, vous pouvez changer la fréquence d’une ou de plusieurs animations par rapport au Storyboard. Le Storyboard parent détermine l’écoulement de la Duration pendant que les animations s’exécutent. Cette propriété n’est pas très souvent utilisée. Pour plus d’informations, consultez SpeedRatio.

Définition de plusieurs animations dans un Storyboard

Le contenu d’un Storyboard peut être plusieurs définitions d’animation. Vous pouvez avoir plusieurs animations si vous appliquez des animations associées à deux propriétés du même objet cible. Par exemple, si vous changez la valeur des propriétés TranslateX et TranslateY d’un TranslateTransform utilisé comme propriété RenderTransform d’un élément d’interface utilisateur, cet élément sera traduit en diagonale. Il vous faut pour cela deux animations différentes, mais il est préférable que les animations appartiennent au même Storyboard, car ces deux animations devront toujours être exécutées ensemble.

Les animations ne doivent pas obligatoirement être du même type ou cibler le même objet. Elles peuvent avoir des durées et des valeurs de propriété différentes.

Lorsque le Storyboard parent s’exécute, chacune des animations qu’il contient s’exécute également.

La classe Storyboard et les types d’animation ont en commun beaucoup de propriétés d’animation, car ils ont la même classe de base Timeline. Par conséquent, un Storyboard peut avoir une propriété RepeatBehavior ou une propriété BeginTime. Vous ne définissez pas ces propriétés sur un Storyboard sauf si vous voulez que toutes les animations qu’il contient aient ce comportement. En règle générale, toute propriété Timeline définie pour un Storyboard s’applique à toutes ses animations enfants. Si cette propriété n’est pas définie, le Storyboard a une durée implicite qui est calculée à partir de la valeur la plus longue de la propriété Duration des animations qu’il contient. Si une propriété Duration définie explicitement sur un Storyboard est plus courte que celle de l’une de ses animations enfants, cette animation sera coupée, ce qui n’est en général pas l’objectif recherché.

Une table de montage séquentiel (storyboard) ne peut pas contenir deux animations qui tentent de cibler et animer la même propriété sur le même objet. Si vous tentez cela, vous obtiendrez une erreur d’exécution lorsque la table de montage séquentiel tente de s’exécuter. Cette restriction s’applique même si les animations ne se chevauchent pas dans le temps en raison de valeurs et de durées BeginTime délibérément différentes. Si vous voulez vraiment appliquer une chronologie d’animation plus complexe à la même propriété dans une table de montage séquentiel, vous devez pour cela utiliser une animation par images clés. Voir Animations par images clés et animations de fonctions d’accélération.

Le système d’animations peut appliquer plusieurs animations à la valeur d’une propriété, si celles-ci proviennent de plusieurs tables de montage séquentiel. L’utilisation délibérée de ce comportement pour des tables de montage séquentiel exécutées simultanément n’est pas courante. Cependant, il est possible qu’une animation définie pour une application que vous appliquez à une propriété d’un contrôle modifie la valeur HoldEnd d’une animation qui a été précédemment exécutée dans le cadre du modèle d’état visuel du contrôle.

Définition d’une table de montage séquentiel en tant que ressource

Un Storyboard est le conteneur dans lequel vous placez des objets d’animation. En général, vous définissez le Storyboard (table de montage séquentiel) en tant que ressource qui est disponible pour l’objet que vous voulez animer, soit dans la propriété Resources au niveau page, soit dans la propriété Application.Resources.

L’exemple suivant montre comment le Storyboard sera contenu dans une définition Resources de niveau page, dans laquelle le Storyboard est une ressource à clé de la Page racine. Notez l’attribut x:Name. Cet attribut vous permet de définir un nom de variable pour le Storyboard afin que d’autres éléments dans le balisage XAML ainsi que le code puissent référencer le Storyboard ultérieurement.

<Page ...>
  <Page.Resources>
    <!-- Storyboard resource: Animates a rectangle's opacity. -->
    <Storyboard x:Name="myStoryboard">
      <DoubleAnimation
        Storyboard.TargetName="MyAnimatedRectangle"
        Storyboard.TargetProperty="Opacity"
        From="1.0" To="0.0" Duration="0:0:1"/>
    </Storyboard>
  </Page.Resources>
  <!--Page root element, UI definition-->
  <Grid>
    <Rectangle x:Name="MyAnimatedRectangle"
      Width="300" Height="200" Fill="Blue"/>
  </Grid>
</Page>

Définir les ressources à la racine XAML d’un fichier XAML tel que page.xaml ou app.xaml est une pratique courante pour organiser les ressources à clé dans le code XAML. Vous pouvez aussi factoriser les ressources dans des fichiers distincts et les fusionner dans des applications ou des pages. Pour plus d’informations, consultez Références aux ressources ResourceDictionary et XAML.

Notes

Windows Runtime XAML prend en charge l’identification des ressources à l’aide de l’attribut x:Key ou de l’attribut x:Name. L’utilisation de l’attribut x:Name est plus courante pour un Storyboard, car vous souhaiterez éventuellement le référencer par nom de variable, afin que vous puissiez appeler sa méthode Begin et exécuter les animations. Si vous utilisez l’attribut x:Key, vous devrez utiliser des méthodes ResourceDictionary telles que l’indexeur Item pour le récupérer en tant que ressource à clé et effectuer un cast de cet objet vers le Storyboard pour utiliser les méthodes Storyboard.

Storyboards pour les états visuels

Vous pouvez aussi placer vos animations dans une unité Storyboard quand vous déclarez les animations d’état visuel pour l’apparence visuelle d’un contrôle. Dans ce cas, les éléments Storyboard que vous définissez vont dans un conteneur VisualState imbriqué plus profondément dans un Style (c’est Style qui est la ressource à clé). Vous n’avez pas besoin de clé ou de nom pour votre Storyboard dans ce cas, car c’est le VisualState qui a un nom cible qui peut être appelé par le VisualStateManager. Les styles des contrôles sont souvent factorisés dans des fichiers XAML ResourceDictionary distincts, plutôt que placés dans une collection Resources de pages ou d’applications. Pour plus d’informations, voir Animations dans une table de montage séquentiel pour les états visuels.

Animations dépendantes et indépendantes

Nous allons maintenant aborder des points importants concernant le fonctionnement du système d’animations. Notamment, l’interaction de l’animation avec le rendu d’une application Windows Runtime à l’écran et l’utilisation des threads de traitement par ce rendu. Une application Windows Runtime comporte toujours un thread d’interface utilisateur principal qui est chargé de mettre à jour l’écran avec les informations actuelles. Elle comporte également un thread de composition qui permet de précalculer des dispositions immédiatement avant qu’elles n’apparaissent. Lorsque vous animez l’interface utilisateur, cela risque de mettre à rude épreuve le thread d’interface utilisateur. Le système doit redessiner de grandes zones de l’écran avec des intervalles assez courts entre chaque actualisation. Cela est nécessaire pour capturer la dernière valeur de la propriété animée. Si vous ne faites pas attention, une animation peut rendre l’interface utilisateur moins réactive ou nuire aux performances d’autres fonctionnalités de l’application se trouvant également sur le même thread d’interface utilisateur.

Une animation qui est considérée comment pouvant ralentir le thread d’interface utilisateur est appelée une animation dépendante. Une animation ne présentant pas ce risque est appelée une animation indépendante. La distinction entre les animations dépendantes et indépendantes n’est pas uniquement déterminée par leur type (DoubleAnimation, etc.) comme nous l’avons décrit auparavant. Elle est déterminée par les propriétés que vous animez et d’autres facteurs tels que l’héritage et la composition des contrôles. Dans certains cas, il peut arriver que, même si une animation change l’interface utilisateur, elle n’ait qu’un impact minime sur le thread d’interface utilisateur. Elle est alors traitée par le thread de composition en tant qu’animation indépendante.

Une animation est indépendante si elle a les caractéristiques suivantes :

Avertissement

Pour que votre animation soit traitée comme indépendante, vous devez définir Duration="0"explicitement . Par exemple, si vous supprimez Duration="0" de ce code XAML, l’animation est traitée comme dépendante, même si le KeyTime de l’image est « 0:0:0 ».

<Storyboard>
  <DoubleAnimationUsingKeyFrames
    Duration="0"
    Storyboard.TargetName="Button2"
    Storyboard.TargetProperty="Width">
    <DiscreteDoubleKeyFrame KeyTime="0:0:0" Value="200"/>
  </DoubleAnimationUsingKeyFrames>
</Storyboard>

Si votre animation ne correspond pas à ces critères, il s’agit probablement d’une animation dépendante. Par défaut, le système d’animations n’exécutera pas une animation dépendante. Par conséquent, au cours du processus de développement et de test, il est possible que vous ne voyiez pas votre animation s’exécuter. Vous pouvez quand même utiliser cette animation, mais vous devez spécifiquement l’activer en tant qu’animation dépendante. Pour activer votre animation, attribuez la valeur true à la propriété EnableDependentAnimation de l’objet animation. (Chaque sous-classe Timeline qui représente une animation implémente différemment cette propriété. Mais toutes les implémentations de cette propriété sont nommées EnableDependentAnimation.)

Le fait que l’activation des animations dépendantes repose sur le développeur d’application est un aspect de conception délibéré du système d’animations et du développement d’applications. Nous voulons que les développeurs tiennent compte du fait que les animations ont un impact sur la réactivité de votre interface utilisateur. Les animations défectueuses sont difficiles à isoler et déboguer dans une application complète. Par conséquent, il est préférable d’activer uniquement les animations dépendantes dont vous avez besoin pour l’interface utilisateur de votre application. Nous ne voulions pas qu’il soit trop facile de compromettre les performances de votre application en raison d’animations décoratives qui utilisent beaucoup de cycles. Pour plus de conseils relatifs aux performances des animations, voir Optimiser les animations et le contenu multimédia.

En tant que développeur d’application, vous pouvez également choisir d’appliquer un paramètre pour toute l’application qui désactive toujours les animations dépendantes, même celles où la propriété EnableDependentAnimation a la valeur true. Consultez Timeline.AllowDependentAnimations.

Conseil

Si vous utilisez le volet Animation dans Blend pour Visual Studio 2019, chaque fois que vous tentez d’appliquer une animation dépendante à une propriété d’état visuel, des avertissements s’affichent dans le concepteur. Les avertissements ne s’affichent pas dans la sortie de build ou la liste d’erreurs. Si vous modifiez le code XAML manuellement, le concepteur n’affiche pas d’avertissement. Lors de l’exécution lors du débogage, la sortie Débogage du volet Sortie affiche un avertissement indiquant que l’animation n’est pas indépendante et est ignorée.

Démarrage et contrôle d’une animation

Tout ce que nous vous avons montré jusqu’à présent n’entraîne pas l’exécution ou l’application d’une animation ! Les changements de valeur qu’une animation déclare en XAML sont latents et ne se produisent que lorsque l’animation démarre et est exécutée. Vous devez explicitement démarrer une animation en tenant compte de la durée de vie de l’application ou de l’expérience utilisateur. Au niveau le plus simple, le démarrage d’une animation s’effectue en appelant la méthode Begin sur le Storyboard qui est le parent de cette animation. Vous ne pouvez pas appeler des méthodes depuis XAML directement ; par conséquent, quoi que vous fassiez pour activer vos animations, vous devrez le faire dans le code. Il pourra s’agir du « code-behind », c’est-à-dire du code des pages ou des composants de votre application, ou peut-être de la logique du contrôle si vous définissez une classe de contrôle personnalisée.

En règle générale, vous allez appeler Begin et laisser l’animation s’exécuter jusqu’à sa fin de durée. Cependant, vous pouvez également utiliser les méthodes Pause, Resume et Stop pour contrôler le Storyboard au moment de l’exécution, ainsi que d’autres API prévues pour des scénarios de contrôle d’animations plus avancés.

Lorsque vous appelez Begin sur un storyboard qui contient une animation qui se répète à l’infini (RepeatBehavior="Forever"), cette animation s’exécute jusqu’à ce que la page qui la contient soit déchargée, ou que vous appelez spécifiquement Pause ou Stop.

Démarrage d’une animation à partir du code de l’application

Vous pouvez démarrer des animations automatiquement ou en réponse à des actions de l’utilisateur. Pour le cas automatique, vous utilisez généralement un événement de durée de vie d’objet tel que Loaded pour agir en tant que déclencheur d’animation. L’événement Loaded est idéal pour cela, car à ce stade, l’interface utilisateur est prête à répondre aux actions de l’utilisateur, et l’animation ne sera pas coupée au début à cause du chargement en cours d’une autre partie de l’interface utilisateur.

Dans notre exemple, l’événement PointerPressed est attaché au rectangle pour que l’animation se lance quand l’utilisateur clique sur le rectangle.

<Rectangle PointerPressed="Rectangle_Tapped"
  x:Name="MyAnimatedRectangle"
  Width="300" Height="200" Fill="Blue"/>

Le gestionnaire d’événements démarre le Storyboard (l’animation) en utilisant la méthode Begin de l’objet Storyboard.

myStoryboard.Begin();

myStoryboard().Begin();

myStoryboard->Begin();

myStoryBoard.Begin()

Vous pouvez gérer l’événement Completed si vous souhaitez qu’une autre logique s’exécute après que l’animation a fini d’appliquer les valeurs. En outre, pour résoudre les problèmes d’interactions entre le système de propriétés et l’animation, la méthode GetAnimationBaseValue peut être utile.

Conseil

Chaque fois que vous codez pour un scénario d’application dans lequel vous démarrez une animation à partir du code d’application, vous pouvez vérifier à nouveau si une animation ou une transition existe déjà dans la bibliothèque d’animations pour votre scénario d’interface utilisateur. Les animations de la bibliothèque s’exécutent de façon homogène sur toutes les applications Windows Runtime et sont plus faciles à utiliser.

 

Animations pour les états visuels

Un Storyboard s’exécute différemment selon s’il est utilisé pour définir l’état visuel d’un contrôle ou si une application l’exécute directement. Appliqué à une définition d’état visuel dans XAML, le Storyboard est un élément d’un VisualState. L’API VisualStateManager, quant à elle, permet de contrôler l’état. Les animations s’exécuteront selon leurs valeurs et les valeurs des propriétés Timeline lorsque le VisualState qui les contient est utilisé par un contrôle. Pour plus d’informations, voir Tables de montage pour les états visuels. Pour les états visuels, le FillBehavior apparent est différent. 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é.

Storyboard et EventTrigger

Il existe un moyen de démarrer une animation qui peut être déclaré entièrement dans XAML. Cependant, cette technique n’est plus courante. Il s’agit d’une syntaxe héritée de WPF et des versions antérieures de Silverlight avant la prise en charge de VisualStateManager . Cette syntaxe de EventTrigger fonctionne toujours dans Windows Runtime XAML pour des raisons d’importation et de compatibilité, mais uniquement comme déclencheur de l’événement FrameworkElement.Loaded. Toute tentative de déclencher d’autres événements lèvera des exceptions ou échouera. Pour plus d’informations, consultez EventTrigger ou BeginStoryboard.

Animation des propriétés XAML jointes

Il ne s’agit pas d’un scénario courant, mais vous pouvez appliquer une valeur animée à une propriété XAML jointe. Pour plus d’informations sur la nature des propriétés jointes et leur fonctionnement, voir Vue d’ensemble des propriétés jointes. Le ciblage des propriétés jointes nécessite une syntaxe de chemin de propriété qui place entre parenthèses le nom de la propriété. Vous pouvez animer les propriétés jointes intégrées telles que Canvas.ZIndex à l’aide d’un ObjectAnimationUsingKeyFrames qui applique des valeurs entières discrètes . Toutefois, une limitation existante d’une implémentation XAML Windows Runtime ne vous permet pas d’animer une propriété jointe personnalisée.

Autres types d’animation et étapes suivantes pour apprendre à animer votre interface utilisateur

Jusqu’à présent nous vous avons montré les animations personnalisées qui s’animent entre deux valeurs et qui interpolent de façon linéaire les valeurs pendant que l’animation s’exécute. Celles-ci sont appelées animations From/To/By . Mais il existe un autre type d’animation qui vous permet de déclarer des valeurs intermédiaires entre le début et la fin de l’animation. Il s’agit des animations par images clés. Il existe également un moyen de modifier la logique d’interpolation sur une animation From/To/By ou une animation d’image clé. Pour cela, il suffit d’appliquer une fonction d’accélération. Pour plus d’informations sur ces concepts, voir Animations par images clés et animations de fonctions d’accélération.