FrameworkElement.GoToElementStateCore(String, Boolean) FrameworkElement.GoToElementStateCore(String, Boolean) FrameworkElement.GoToElementStateCore(String, Boolean) FrameworkElement.GoToElementStateCore(String, Boolean) Method


When implemented in a derived class, enables per-state construction of a visual tree for a control template in code, rather than by loading XAML for all states at control startup.

protected : virtual Platform::Boolean GoToElementStateCore(Platform::String stateName, bool useTransitions)
virtual bool GoToElementStateCore(winrt::hstring stateName, bool useTransitions) const;
protected virtual bool GoToElementStateCore(String stateName, Boolean useTransitions)
Protected Overridable Function GoToElementStateCore(stateName As String, useTransitions As Boolean) As bool


String String

The state to transition to.

Boolean Boolean

true to use a VisualTransition to transition between states. false to skip using transitions and go directly to the requested state. The default is false.


bool bool

true if the control successfully transitions to the new state, or was already using that state; otherwise, false.


The default implementation of FrameworkElement.GoToElementStateCore provides the normal state change behavior that's accessed by calling VisualStateManager.GoToState, and also the default control template / visual state loading behavior for any XAML control. You should only override FrameworkElement.GoToElementStateCore if you are prepared to take full responsibility for constructing the visual tree for a control in your code at run time. This includes presentation of any content that comes from content properties, child element collections, and so on.

For general state change logic in a custom control, you should use VisualStateManager.GoToState. The intended scenario for FrameworkElement.GoToElementStateCore is more limited, it's specifically intended for apps or controls that want to optimize the template or logic that creates the visual tree of a ListViewItem or a GridViewItem and presents the contents.

VisualStateManager.GoToState has a slightly different signature because it's a static utility API and uses a control parameter to specify what control to apply state changes to. FrameworkElement.GoToElementStateCore uses the calling object to get this information.

See also