VisualState Classe

Définition

public ref class VisualState sealed : DependencyObject

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

[Microsoft.UI.Xaml.Markup.ContentProperty(Name="Storyboard")]
[Windows.Foundation.Metadata.Activatable(65536, "Microsoft.UI.Xaml.WinUIContract")]
[Windows.Foundation.Metadata.ContractVersion(typeof(Microsoft.UI.Xaml.WinUIContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
[Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
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

ContentPropertyAttribute ActivatableAttribute ContractVersionAttribute MarshalingBehaviorAttribute ThreadingAttribute

Exemples

Cet exemple crée un VisualStateGroup dans le ControlTemplate d’un button appelé « CommonStates » et ajoute VisualState des objets pour les états, « Normal », « Pressed » et « PointerOver ». Définit Button é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 VisualState élément doit toujours être contenu dans un parent VisualStateGroup dans le balisage XAML. A VisualStateGroup une propriété de collection implicite States, vous pouvez donc placer chacun VisualState en tant qu’élément enfant immédiat du VisualStateGroup parent. 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 VisualState tel utilise 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.

Lorsque vous utilisez StateTriggers, vous n’êtes plus obligé de créer un vide VisualState 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 correspondant VisualState 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 stateName paramètre pour indiquer à VisualStateManager quel état doit être utilisé comme état actuel. Spécifiez un attribut x:Name pour chaque VisualState attribut qui doit être appliqué manuellement à l’aide d’un GoToState appel à 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 de l’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 qui fournissent VisualTransition 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ù existe le 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 Name propriété, mais celles-ci sont en lecture seule. Cette Name propriété 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 Modèles de contrôle XAML.

Lorsque vous remplacez un modèle de contrôle, il est important de reproduire tous les éléments nommés VisualState existants à partir du contenu du modèle de VisualStateManager.VisualStateGroups 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 manquant VisualState 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 un VisualState « Vérifié » nommé 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 de visuellement différent pour distinguer un vérifié CheckBox d’un non vérifié CheckBox. 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 nommés VisualState 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 stateName valeur qu’un consommateur de contrôle passerait dans un appel GoToState pour utiliser cet état visuel. Si fait VisualState partie d’un VisualStateGroup, cela doit également être indiqué dans vos valeurs d’attribut.

Constructeurs

Propriétés

Méthodes

S’applique à

Voir aussi

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