VisualState Classe

Définition

Espace de noms:

Windows.UI.Xaml

Représente l’apparence visuelle d’un élément d’interface utilisateur lorsqu’il se trouve dans un état spécifique. Les états visuels utilisent des setters ou un storyboard pour définir les propriétés de l’interface utilisateur dans les pages ou les modèles de contrôle où VisualState est défini.

public ref class VisualState sealed : DependencyObject

/// [Windows.Foundation.Metadata.ContractVersion(Windows.Foundation.UniversalApiContract, 65536)]
/// [Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
/// [Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
/// [Windows.UI.Xaml.Markup.ContentProperty(Name="Storyboard")]
/// [Windows.Foundation.Metadata.Activatable(65536, "Windows.Foundation.UniversalApiContract")]
class VisualState final : DependencyObject

[Windows.Foundation.Metadata.ContractVersion(typeof(Windows.Foundation.UniversalApiContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
[Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
[Windows.UI.Xaml.Markup.ContentProperty(Name="Storyboard")]
[Windows.Foundation.Metadata.Activatable(65536, "Windows.Foundation.UniversalApiContract")]
public sealed class VisualState : DependencyObject

Public NotInheritable Class VisualState
Inherits DependencyObject

<VisualState x:Name="stateName" />
-or-
<VisualState x:Name="stateName">
  singleStoryboard
</VisualState>
-or-
<VisualState x:Name="stateName">
  <VisualState.Setters>
    oneOrMoreSetters
  </VisualState.Setters>
  [optional]singleStoryboard
</VisualState>
-or-
<VisualState x:Name="stateName">
  <VisualState.StateTriggers>
    oneOrMoreTriggers
  </VisualState.StateTriggers>  
  <VisualState.Setters>
    oneOrMoreSetters
  </VisualState.Setters>
  [optional]singleStoryboard
</VisualState>

Héritage

Object Platform::Object IInspectable DependencyObject VisualState

Attributs

ActivatableAttribute ContractVersionAttribute MarshalingBehaviorAttribute ThreadingAttribute ContentPropertyAttribute

Configuration requise pour Windows

Famille d’appareils	Windows 10 (introduit dans 10.0.10240.0)
API contract	Windows.Foundation.UniversalApiContract (introduit dans v1.0)

Exemples

Cet exemple crée un VisualStateGroup dans le ControlTemplate d’un button appelé « CommonStates » et ajoute des objets VisualState pour les états, « Normal », « Pressed » et « PointerOver ». Le bouton définit également un état appelé « Disabled » qui se trouve dans les « CommonStates » nommés VisualStateGroup, mais l’exemple l’omet par souci de concision.

<ControlTemplate TargetType="Button">
  <Border x:Name="RootElement">

    <VisualStateManager.VisualStateGroups>

      <!--Define the states for the common states.
          The states in the VisualStateGroup are mutually exclusive to
          each other.-->
      <VisualStateGroup x:Name="CommonStates">

        <!--The Normal state is the state the button is in
            when it is not in another state from this VisualStateGroup.-->
        <VisualState x:Name="Normal" />

        <!--Change the SolidColorBrush, BorderBrush, to red when the
            Pointer is over the button.-->
        <VisualState x:Name="PointerOver">
          <Storyboard>
            <ColorAnimation Storyboard.TargetName="BorderBrush" 
                              Storyboard.TargetProperty="Color" To="Red" />

          </Storyboard>

        </VisualState>

        <!--Change the SolidColorBrush, BorderBrush, to Transparent when the
            button is pressed.-->
        <VisualState x:Name="Pressed">
          <Storyboard >
            <ColorAnimation Storyboard.TargetName="BorderBrush" 
                              Storyboard.TargetProperty="Color" To="Transparent"/>
          </Storyboard>
        </VisualState>
          <!--The Disabled state is omitted for brevity.-->
        </VisualStateGroup>
  
    </VisualStateManager.VisualStateGroups>
    

    <Border.Background>
      <SolidColorBrush x:Name="BorderBrush" Color="Black"/>
    </Border.Background>

    <Grid Background="{TemplateBinding Background}" Margin="4">
      <ContentPresenter
        HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
        VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
        Margin="4,5,4,4" />

    </Grid>


  </Border>
</ControlTemplate>

<Page>
    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <VisualStateManager.VisualStateGroups>
            <VisualStateGroup>
                <VisualState>
                    <VisualState.StateTriggers>
                        <!-- VisualState to be triggered when window width is >=720 effective pixels -->
                        <AdaptiveTrigger MinWindowWidth="720"/>
                    </VisualState.StateTriggers>
                    <VisualState.Setters>
                        <Setter Target="myPanel.Orientation" Value="Horizontal"/>
                    </VisualState.Setters>
                </VisualState>
            </VisualStateGroup>
        </VisualStateManager.VisualStateGroups>
        <StackPanel x:Name="myPanel" Orientation="Vertical">
            <TextBlock x:Name="myTextBlock" MaxLines="5" Style="{ThemeResource BodyTextBlockStyle}"/>
        </StackPanel>
    </Grid>
</Page>

Remarques

Un élément VisualState doit toujours être contenu dans un parent VisualStateGroup dans le balisage XAML. VisualStateGroup a une propriété de collection implicite States. Vous pouvez donc placer chaque VisualState en tant qu’élément enfant immédiat du parent VisualStateGroup. Par exemple :

<VisualStateGroup x:Name="CommonStates">
   <VisualState x:Name="Normal"/>
   <VisualState x:Name="PointerOver">...</VisualState>
<!-- do not need explicit VisualStateGroups.States property element, States is the XAML content property-->
</VisualStateGroup>

Lorsque vous utilisez StateTriggers, vérifiez que VisualStateGroup est déclaré sous le premier enfant de la racine afin que les déclencheurs prennent effet automatiquement.

État par défaut

Il est légal et courant de définir un VisualState qui a un attribut x:Name , mais qui ne spécifie rien dans le Storyboard. Cela est utile, car un tel VisualState utilisera les valeurs présentes dans le modèle par défaut. Vous pouvez ensuite demander spécifiquement l’état vide à partir d’un appel GoToState . Lorsqu’un état vide devient l’état actuel, cela annule toutes les modifications apportées aux propriétés de modèle par un état visuel précédent à partir du même VisualStateGroup. Pour plus d’informations sur l’utilisation des groupes pour les états visuels, consultez Animations de storyboard pour les états visuels.

Lorsque vous utilisez StateTriggers, vous n’êtes plus obligé de créer un VisualState vide pour appeler GoToState sur. Lorsque les conditions d’un StateTrigger ne sont plus remplies, toutes les modifications apportées aux propriétés par le VisualState correspondant sont automatiquement supprimées et les valeurs fournies dans le balisage par défaut prennent effet.

VisualState et x:Name

La méthode GoToState (qui est généralement appelée à partir du code de contrôle) nécessite un paramètre stateName pour indiquer à VisualStateManager quel état doit être utilisé comme état actuel. Spécifiez un attribut x:Name pour chaque VisualState qui doit être appliqué manuellement à l’aide d’un appel GoToState à partir du code. Si vous utilisez StateTriggers pour déclencher automatiquement un VisualState à partir du balisage, vous n’avez pas besoin de spécifier un attribut x:Name sur ce VisualState.

Si vous utilisez des transitions visuelles, la valeur d’attribut x:Name d’un VisualState est également référencée par les valeurs From ou To d’un VisualTransition. Dans ce cas, le nom identifie l’état ou les états que VisualTransition fournit les valeurs intermédiaires entre.

La valeur de l’attribut x:Name que vous spécifiez pour un VisualState doit être unique dans le modèle de contrôle XAML où se trouve VisualState. L’étendue des noms d’état n’est pas limitée à chaque VisualStateGroup, elle est étendue à tous les états visuels du modèle. Par exemple, vous ne pouvez pas définir deux états différents nommés « Prioritaire » dans le même modèle XAML, même s’ils se trouvent dans des groupes différents.

Vous devez utiliser l’attribut x:Name pour nommer un état visuel ou un groupe d’états visuels ; L’attribut « Name » non corrigé ne fonctionnera pas. VisualState et VisualStateGroup ont chacun une propriété Name , mais celles-ci sont en lecture seule. Cette propriété Name existe pour les scénarios avancés qui utilisent du code pour examiner le contenu d’un modèle de contrôle au moment de l’exécution, et non pour la définition à partir de XAML.

Remplacement du modèle de contrôle d’un contrôle existant

Si vous êtes développeur d’applications utilisant un contrôle dans l’interface utilisateur de votre application, vous pouvez remplacer le modèle de contrôle en définissant la propriété Control.Template sur une valeur différente. Vous pouvez également remplacer le modèle en déclarant un nouveau style qui utilise la clé de style implicite pour ce contrôle. Pour plus d’informations sur ces concepts, consultez Démarrage rapide : Modèles de contrôle.

Lorsque vous remplacez un modèle de contrôle, il est important de reproduire tous les éléments Nommés VisualState existants du contenu VisualStateManager.VisualStateGroups du modèle de contrôle d’origine en XAML. Le code de contrôle (que vous ne modifiez pas) appelle GoToState. Les états portant ces noms doivent exister dans le modèle de contrôle. Une demande pour un VisualState manquant ne lève pas d’exceptions, mais elle laisse souvent le contrôle dans un état visuel qui prêtera à confusion pour l’utilisateur. Par exemple, si vous ne fournissez pas de VisualState nommé « Checked » pour un contrôle CheckBox , aucun retour visuel n’apparaît lorsque l’utilisateur sélectionne le contrôle. L’utilisateur s’attend à ce qu’il y ait quelque chose visuellement différent pour distinguer une CheckBox cochée d’une CheckBox non cochée. Ainsi, si vous ne parviens pas à reproduire les états visuels de la part du développeur de l’application, le contrôle semble rompu à l’utilisateur.

Lorsque vous utilisez un IDE tel que Microsoft Visual Studio, les actions que vous utilisez pour remplacer un modèle de contrôle offrent la possibilité de commencer par une copie du modèle XAML d’origine, afin que vous puissiez voir tous les éléments VisualState nommés d’origine et d’autres composition de contrôle que vous remplacez. Il est préférable de commencer par des copies de modèles, puis de les modifier, afin de ne pas omettre accidentellement un état visuel attendu de votre nouveau modèle.

Attribution des états visuels nommés d’un contrôle personnalisé

Si vous définissez un contrôle personnalisé qui a des états visuels dans son modèle de contrôle XAML, il est recommandé d’attribuer la classe de contrôle pour indiquer aux consommateurs quels états visuels sont disponibles. Pour ce faire, appliquez un ou plusieurs attributs TemplateVisualState au niveau de la classe de votre code de définition de contrôle. Chaque attribut doit spécifier l’attribut x:Name de l’état, qui est la valeur stateName qu’un consommateur de contrôle passerait dans un appel GoToState pour utiliser cet état visuel. Si VisualState fait partie d’un VisualStateGroup, cela doit également être indiqué dans vos valeurs d’attribut.

Constructeurs

VisualState()

Initialise une nouvelle instance de la classe VisualState.

Propriétés

Dispatcher	Obtient le CoreDispatcher auquel cet objet est associé. CoreDispatcher représente une fonctionnalité qui peut accéder à DependencyObject sur le thread d’interface utilisateur, même si le code est initié par un thread autre que l’interface utilisateur. (Hérité de DependencyObject)
Name	Obtient le nom de VisualState.
Setters	Obtient une collection d’objets Setter qui définissent des valeurs de propriété discrètes qui contrôlent l’apparence des UIElementquand cet objet VisualState est appliqué.
StateTriggers	Obtient une collection d’objets StateTriggerBase qui indiquent quand ce VisualState doit être appliqué. Si l’un des déclencheurs (pas tous) est actif, visualState est appliqué.
Storyboard	Obtient ou définit un Storyboard qui définit des valeurs de propriété spécifiques à l’état et l’apparence du contrôle lorsqu’il utilise cet état visuel.

Méthodes

ClearValue(DependencyProperty)	Efface la valeur locale d’une propriété de dépendance. (Hérité de DependencyObject)
GetAnimationBaseValue(DependencyProperty)	Retourne toute valeur de base établie pour une propriété de dépendance, qui s’appliquerait dans les cas où une animation n’est pas active. (Hérité de DependencyObject)
GetValue(DependencyProperty)	Retourne la valeur effective actuelle d’une propriété de dépendance à partir d’un DependencyObject. (Hérité de DependencyObject)
ReadLocalValue(DependencyProperty)	Retourne la valeur locale d’une propriété de dépendance, si une valeur locale est définie. (Hérité de DependencyObject)
RegisterPropertyChangedCallback(DependencyProperty, DependencyPropertyChangedCallback)	Inscrit une fonction de notification pour écouter les modifications apportées à un DependencyProperty spécifique sur ce instance DependencyObject. (Hérité de DependencyObject)
SetValue(DependencyProperty, Object)	Définit la valeur locale d’une propriété de dépendance sur un DependencyObject. (Hérité de DependencyObject)
UnregisterPropertyChangedCallback(DependencyProperty, Int64)	Annule une notification de modification précédemment inscrite en appelant RegisterPropertyChangedCallback. (Hérité de DependencyObject)

Voir aussi

• DependencyObject
• VisualStateGroup
• Animations dans une table de montage séquentiel pour les états visuels
• Animations dans une table de montage séquentiel
• Attribut x:Name
• Démarrage rapide : Modèles de contrôle
• Exemple de contrôle XAML et de style d’application
• Exemple maître/détail (Windows 10)