VisualStateGroup Classe

Definizione

public ref class VisualStateGroup sealed : DependencyObject

/// [Microsoft.UI.Xaml.Markup.ContentProperty(Name="States")]
/// [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 VisualStateGroup final : DependencyObject

[Microsoft.UI.Xaml.Markup.ContentProperty(Name="States")]
[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 VisualStateGroup : DependencyObject

Public NotInheritable Class VisualStateGroup
Inherits DependencyObject

<VisualStateManager.VisualStateGroups>
   <VisualStateGroup x:Name="groupname" ...>
     oneOrMoreVisualStates
   </VisualStateGroup>
   <!--- other peer VisualStateGroup's here ... -->
</VisualStateManager.VisualStateGroups>

Ereditarietà

Object Platform::Object IInspectable DependencyObject VisualStateGroup

Attributi

ContentPropertyAttribute ActivatableAttribute ContractVersionAttribute MarshalingBehaviorAttribute ThreadingAttribute

Esempio

In questo esempio viene creato un oggetto ControlTemplate semplice per un controllo Button contenente una griglia. Contiene anche un VisualStateGroup denominato "CommonStates", che definisce gli stati "PointerOver" e "Normal". L'oggetto VisualStateGroup dispone inoltre di un oggetto VisualTransition che specifica che l'oggetto Grid deve passare da verde a rosso quando l'utente inserisce il puntatore su Button.

<ControlTemplate TargetType="Button">
  <Grid >
    <VisualStateManager.VisualStateGroups>
      <VisualStateGroup x:Name="CommonStates">

        <VisualStateGroup.Transitions>

          <!--Take one half second to transition to the PointerOver state.-->
          <VisualTransition To="PointerOver" 
                              GeneratedDuration="0:0:0.5"/>
        </VisualStateGroup.Transitions>
        
        <VisualState x:Name="Normal" />

        <!--Change the SolidColorBrush, ButtonBrush, to red when the
            Pointer is over the button.-->
        <VisualState x:Name="PointerOver">
          <Storyboard>
            <ColorAnimation Storyboard.TargetName="ButtonBrush" 
                            Storyboard.TargetProperty="Color" To="Red" />
          </Storyboard>
        </VisualState>
      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
    <Grid.Background>
      <SolidColorBrush x:Name="ButtonBrush" Color="Green"/>
    </Grid.Background>
  </Grid>
</ControlTemplate>

Commenti

Ogni VisualStateGroup attributo dichiarato in XAML come parte di un modello di controllo deve sempre avere un attributo x:Name impostato su di esso. Ogni stringa di nome usata nel set di in un modello di VisualStateGroups controllo deve essere univoca in tale modello. È comune usare gli stessi nomi di gruppo per controlli diversi. Ad esempio, quasi tutti i modelli di controllo esistenti hanno un VisualStateGroup oggetto con x:Name attribute "CommonStates".

Il set di stati di visualizzazione all'interno di ogni VisualStateGroup oggetto deve essere a vicenda esclusivo nel gruppo. In altre parole, il controllo deve usare esattamente uno degli stati di visualizzazione di ognuno dei relativi gruppi definiti VisualStateGroup in qualsiasi momento. Ogni volta che si verifica un caso in cui un controllo deve essere contemporaneamente in due stati, assicurarsi che i due stati si trovino in gruppi diversi. Ad esempio, è possibile che un controllo a discesa sia attivo contemporaneamente e che l'elenco a discesa sia aperto. In una progettazione dello stato di visualizzazione corretta, si dispone di un separato VisualStateGroup per ogni stato in modo che possano essere entrambi attivi contemporaneamente. Tali gruppi potrebbero avere nomi come "FocusStates" e "DropDownStates".

Ogni volta che si definisce un oggetto VisualStateGroup che abilita un comportamento di storyboard temporaneo in uno degli elementi VisualState , assicurarsi che il gruppo contenga anche un secondo VisualState che può essere chiamato per annullare lo stato precedente. Questo può essere semplice come dichiarare il secondo VisualState senza storyboard , solo un attributo x:Name.

Il valore dell'attributo x:Name impostato per un VisualStateGroup oggetto non viene usato per una chiamata a VisualStateManager.GoToState, ma è l'oggetto x:Name attribute di un oggetto VisualState usato per VisualStateManager.GoToState. Chiunque usi VisualStateManager.GoToState deve essere a conoscenza di tutti i gruppi e degli stati disponibili, in modo che ogni chiamata passi correttamente da stati precedenti a nuovi stati all'interno di un gruppo.

Oltre a un set di elementi VisualState , un VisualStateGroup oggetto può anche definire un set di elementi VisualTransition , in cui ogni VisualTransition elemento si riferisce ad almeno uno degli elementi denominati VisualState definiti nel gruppo. In XAML, il set di VisualState elementi può essere dichiarato come elementi figlio dell'elemento VisualStateGroupoggetto immediato di . Ciò è possibile perché la proprietà States , che è la raccolta di stati di visualizzazione, è la proprietà del contenuto XAML per VisualStateGroup. Al contrario, per impostare la raccolta di transizioni visive, devi dichiarare tale raccolta all'interno di un elemento della proprietà VisualStateGroup.Transitions in XAML. Per altre info sulle proprietà del contenuto XAML, vedi guida alla sintassi XAML.

Quando si usano StateTriggers per controllare gli stati di visualizzazione, il motore di trigger usa le regole di precedenza seguenti per assegnare punteggi ai trigger e determinare quale trigger e l'oggetto VisualState corrispondente saranno attivi:

1. Trigger personalizzato che deriva da StateTriggerBase
2. AdaptiveTrigger attivato a causa di MinWindowWidth
3. AdaptiveTrigger attivato a causa di MinWindowHeight

Se sono presenti più trigger attivi alla volta che presentano un conflitto nell'assegnazione dei punteggi (ad esempio due trigger personalizzati attivi), il primo dichiarato nel file di markup ha la precedenza.

Nota: mentre AdaptiveTrigger deriva da StateTriggerBase, può essere attivato solo impostando MinWindowWidth e/o MinWindowHeight.

Visualstategroup API che supportano l'implementazione personalizzata di VisualStateManager

Molte API di VisualStateGroup esistono solo per supportare l'implementazione personalizzata di VisualStateManager . Questi includono: Name, CurrentState, CurrentStateChanging, CurrentStateChanged. Gli utilizzi più comuni degli stati di visualizzazione per i modelli di controllo non richiederanno queste API. In particolare, non è tipico gestire gli eventi. La maggior parte delle operazioni logiche per un controllo deve includere proprietà ed eventi specifici. Per la maggior parte degli scenari di definizione delle app e dei controlli, le modifiche dello stato visivo apportate al controllo devono essere solo un risultato finale della logica applicata al relativo modello, non un trigger per altre logiche.

Vedi anche

• DependencyObject
• VisualStateManager
• VisualState
• Modelli di controllo XAML
• Animazioni storyboardate
• Esempio di applicazione e controllo XAML