VisualStateManager.GoToStateCore Method
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
When overridden in a derived class, transitions a control between states.
protected:
virtual bool GoToStateCore(Control ^ control, FrameworkElement ^ templateRoot, Platform::String ^ stateName, VisualStateGroup ^ group, VisualState ^ state, bool useTransitions) = GoToStateCore;
bool GoToStateCore(Control const& control, FrameworkElement const& templateRoot, winrt::hstring const& stateName, VisualStateGroup const& group, VisualState const& state, bool const& useTransitions);
protected virtual bool GoToStateCore(Control control, FrameworkElement templateRoot, string stateName, VisualStateGroup group, VisualState state, bool useTransitions);
function goToStateCore(control, templateRoot, stateName, group, state, useTransitions)
Protected Overridable Function GoToStateCore (control As Control, templateRoot As FrameworkElement, stateName As String, group As VisualStateGroup, state As VisualState, useTransitions As Boolean) As Boolean
Parameters
- control
- Control
The control to transition between states.
- templateRoot
- FrameworkElement
The root element of the control's ControlTemplate.
- stateName
-
String
Platform::String
winrt::hstring
The name of the state to transition to.
- group
- VisualStateGroup
The VisualStateGroup that the state belongs to.
- state
- VisualState
The representation of the state to transition to.
- useTransitions
-
Boolean
bool
true
to use a VisualTransition to transition between states; otherwise, false
.
Returns
bool
true
if the control successfully transitions to the new state; otherwise, false
.
Remarks
This API is part of the scenario of defining a custom VisualStateManager behavior. Overriding GoToStateCore
changes the state behavior in your custom class behavior.
To reference your custom VisualStateManager class, set the value of the VisualStateManager.CustomVisualStateManager attached property within any control template where you want to use the custom VisualStateManager
class behavior. You typically create an instance of the custom VisualStateManager
class through default XAML construction in Application.Resources. Then the VisualStateManager.CustomVisualStateManager
attached property is set using a {StaticResource} markup extension reference to the key of the custom VisualStateManager
resource.
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 thegroup
, your implementation should returnfalse
. - If the control is already in the VisualState requested as
stateName
, your implementation should returntrue
.
For more info on the default behavior, see GoToState.
Events for visual state changes
CurrentStateChanging fires when the control begins to transition states as requested by the GoToState call. If a VisualTransition is applied to the state change, this event occurs when the transition begins.
CurrentStateChanged fires after the control is in the state as requested by the GoToState call, just as the new Storyboard begins. No event is fired on the new storyboard's completion.
If a VisualTransition is not applied, CurrentStateChanging and CurrentStateChanged fire in quick succession, but are guaranteed in that order if both occur.
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.
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.