Definition

Manages visual states and the logic for transitions between visual states for controls. Also provides the attached property support for VisualStateManager.VisualStateGroups, which is how you define visual states in XAML for a control template.

The particular set of visual states contains one VisualStateGroup, called "CommonStates", which defines the "PointerOver" and "Normal"**VisualState objects. When the user puts the pointer over the Button, the Grid changes from green to red in .5 seconds. When the user moves the pointer away from the button, the Grid immediately changes back to green.

Control authors or app developers transition between these states by calling the static GoToState method of VisualStateManager. Control authors do this whenever the control logic handles events that indicate a change of state, or control logic initiates a state change by itself. It's more common for control definition code to do this rather than app code, so that all the possible visual states and their transitions and trigger conditions are there by default for app code, and the logic is encapsulated by the control.

When you edit copies of styles as enabled by the XAML design surface of Microsoft Visual Studio, the visual states from the default template are defined in the XAML you are editing. Make sure you don't delete these states or change their names, because the control logic is expecting that these visual states exist in the template.

In addition to the visual states, the visual state model also includes transitions. Transitions are animation actions controlled by a Storyboard that occur between each visual state when the state is changed. The transition can be defined differently for each combination of starting state and ending state as defined by your control's set of visual states. Transitions are defined by the Transitions property of VisualStateGroup, in XAML using property element syntax. Most default control templates don't define transitions. In absence of specifically defined transitions, the transitions between states happen instantaneously (zero-duration). For more info, see VisualTransition.

Visual states for elements that aren't controls

Visual states are sometimes useful for scenarios where you want to change the state of some area of UI that's not immediately a Control subclass. You can't do this directly because the control parameter of the GoToState method requires a Control subclass, which refers to the object that the VisualStateManager acts upon. Page is a Control subclass, and it's fairly rare that you'd be showing UI in a context where you don't have a Page, or your Window.Content root isn't a Control subclass. We recommend you define a custom UserControl to either be the Window.Content root or be a container for other content you want to apply states to (such as a Panel ). Then you can call GoToState on your UserControl and apply states regardless of whether the rest of the content is a Control. For example you could apply visual states to UI that otherwise consists of just a SwapChainPanel so long as you placed that within your UserControl and declared named states that apply to the properties of the parent UserControl or of the named SwapChainPanel part of the template.

public : static VisualStateManager GetCustomVisualStateManager(FrameworkElement obj)public static VisualStateManager GetCustomVisualStateManager(FrameworkElement obj)Public Static Function GetCustomVisualStateManager(obj As FrameworkElement) As VisualStateManager// This API is not available in Javascript.

public : static IVector<VisualStateGroup> GetVisualStateGroups(FrameworkElement obj)public static IList<VisualStateGroup> GetVisualStateGroups(FrameworkElement obj)Public Static Function GetVisualStateGroups(obj As FrameworkElement) As IList( Of VisualStateGroup )// This API is not available in Javascript.

Remarks

This method is used by control logic. You typically only need it if you are writing a custom control, or if you are using app-level logic for view states (such as refreshing your app content for changes in app window size or orientation).

When you call this method, there is expected to be a VisualState with an x:Name value that matches your stateName value, somewhere in the control template for the control identified by control, or as a resource for your app. If there isn't, you don't get exceptions, but the return value will be false. The state named by stateName can be in any of the VisualStateGroup elements in the template for the specified Control. It's up to you to keep track of which states are in which VisualStateGroup and knowing which state gets unloaded when you specify a new state from that group.

Typically the ControlTemplate that contains the visual states as referenced by name when using GoToState is not specifically defined for that control instance. Instead the visual states are from the default control style that's loaded as the implicit style for all instances of that control. For more info on the implicit style concept, see Quickstart: Control templates.

VisualStateManager supports two important features for control authors, and for app developers who are applying a custom template to a control:

Control authors or app developers transition between these states by calling the static GoToState method of VisualStateManager. Control authors do this whenever the control logic handles events that indicate a change of state, or control logic initiates a state change by itself. It's more common for control definition code to do this rather than app code, so that all the possible visual states and their transitions and trigger conditions are there by default for app code. Or, it's the app code that is changing visual states, to manage app-level view states in response to user-driven changes to the size or orientation of the main app window.

If the VisualState that the control was using from that same VisualStateGroup prior to the newly requested state has a Storyboard, that storyboard stops. Other than the specific properties that the new VisualState applies an animation to, the control reverts to the initially loaded states from the control template and its composition.

If the control is already in the VisualState requested as stateName, GoToState returns true, but there is otherwise no action (the storyboard won't be restarted).

A common control implementation pattern is to define a single private method of the control class that takes care of all possible VisualState changes for the control. Which visual state to use is determined by checking the control's properties. These properties might be public or private. Values of properties are adjusted by handlers in control logic for events such as OnGotFocus, and are checked just-in-time immediately before setting the visual state. The code example in this topic uses this implementation pattern. Alternatively, you can call GoToState for individual states from within event handlers, from control event handler overrides (the On* methods), or from helper methods that are called by all possible impetus for changing states (user-driven events, automation events, initialization logic).

Visual states and transitions

In addition to the visual states, the visual state model also includes transitions. Transitions are animation actions controlled by a Storyboard that occur between each visual state when the state is changed. The transition can be defined differently for each combination of starting state and ending state as defined by your control's set of visual states. Transitions are defined by the Transitions property of VisualStateGroup and are usually defined in XAML. Most default control templates don't define transitions, and in this case the transitions between states happen instantaneously. For more info, see VisualTransition.

A VisualTransition can also be defined such that it produces an implicit transition. Any dependency property that is specifically targeted for animation in either the From or@Windows.UI.Xaml.VisualTransition.To?text=To visual states of a VisualTransition and has different values across the state change can be animated with an implicit transition animation. This generated animation transitions between the From state value and the To state value of such a property using interpolation. The implicit transition animation lasts for the time stated by the GeneratedDuration value of a VisualTransition. Implicit transitions only apply to properties that are a Double, Color or Point value. In other words the property must be possible to implicitly animate using a DoubleAnimation, PointAnimation or ColorAnimation. For more info, see GeneratedDuration.

However, if a state change transition is interrupted by a new GoToState call, the CurrentStateChanged event is never raised for the first state transition. A new event series is fired for the next requested state change.

Attributing a custom control's named visual states

If you are defining a custom control that has visual states in its control template XAML, it's a best practice to attribute the control class to indicate to control consumers which visual states are available. To do this, apply one or more TemplateVisualState attributes at the class level of your control definition code. Each attribute should specify the state's x:Name attribute, which is the stateName value a control consumer would pass in a GoToState call to use that visual state. If the VisualState is part of a VisualStateGroup, that should also be indicated in the attribute definition.

A related concept is that control authors should attribute the names of key control parts using TemplatePartAttribute. This is very helpful if control consumers want to access named parts from the template scope after the template is applied. TemplateVisualStateAttribute and TemplatePartAttribute combined help define the control contract for a control.

Visual states for app view states

Visual states aren't necessarily for custom controls. You can use visual states from new control templates that you apply to any Control instance where you're replacing the default template by setting the Template property. To set this up, you must define the control template and visual states that you're planning on using as a Style resource that's in either Page.Resources or Application.Resources. It's always best to start with a copy of the default template and modify only certain aspects of the template or even just modify some of the visual states and leave the basic composition alone. For more info, see Quickstart: Control templates.

Visual states can be used to change properties of a Page or controls within the page to account for app window orientation. Your composition or your control's layout-related property values might change depending on whether the overall orientation is portrait or landscape. For more info about this scenario for GoToState, see Quickstart: Designing apps for different window sizes.

Visual states for elements that aren't controls

Visual states are sometimes useful for scenarios where you want to change the state of some area of UI that's not immediately a Control subclass. You can't do this directly because the control parameter of the GoToState method requires a Control subclass, which refers to the object that the VisualStateManager acts upon. Page is a Control subclass, and it's fairly rare that you'd be showing UI in a context where you don't have a Page, or your Window.Content root isn't a Control subclass. We recommend you define a custom UserControl to either be the Window.Content root or be a container for other content you want to apply states to (such as a Panel ). Then you can call GoToState on your UserControl and apply states regardless of whether the rest of the content is a Control. For example you could apply visual states to UI that otherwise consists of just a SwapChainPanel so long as you placed that within your UserControl and declared named states that apply to the properties of the parent UserControl or of the named SwapChainPanel part of the template.

Notes to inheritors

When a consumer of your custom VisualStateManager class calls GoToState to change the visual state of a control, this is the default behavior you are overriding:+ If the VisualState as named by stateName has a Storyboard, the storyboard begins.

If the VisualState that the control was using prior to the newly requested state has a Storyboard, that storyboard stops.
If a VisualState for stateName doesn't exist in the group, your implementation should return false.

If the control is already in the VisualState requested as stateName, your implementation should return true.

However, if a state change transition is interrupted by a new GoToState call, the CurrentStateChanged event is never raised for the first state transition. A new event series is fired for the next requested state change.

Remarks

This API is part of the scenario of defining a custom VisualStateManager behavior. The most important method to override in this scenario is GoToStateCore, because it's that method that changes the state behavior in your custom class behavior. Overriding the behavior of RaiseCurrentStateChanged and RaiseCurrentStateChanging is optional: how and when the events are raised by the default implementation might be adequate for your custom class.

Remarks

This API is part of the scenario of defining a custom VisualStateManager behavior. The most important method to override in this scenario is GoToStateCore, because it's that method that changes the state behavior in your custom class behavior. Overriding the behavior of RaiseCurrentStateChanged and RaiseCurrentStateChanging is optional: how and when the events are raised by the default implementation might be adequate for your custom class.