Description
Similar to #34721 (Style reapplication), when VisualStateGroup setters are mutated in-place (e.g., a VisualState's Setter Value is changed), the framework does not reapply the visual state to the target element.
VisualStateGroupList validates group/state name uniqueness on Add() via WatchAddList, but there is no mechanism to re-evaluate and reapply the current visual state after setter mutations.
Motivation
Hot Reload scenarios (including XAML Incremental Hot Reload) need to update VSM setters in-place and have the changes reflected on the element. Currently there is no way to force reapplication of the current visual state without reconstructing the entire VisualStateGroup hierarchy.
Proposed API
// Force re-evaluation and reapplication of the current visual state
VisualStateManager.InvalidateVisualStates(VisualElement element);
Or an internal API if this should not be public.
Related
Description
Similar to #34721 (Style reapplication), when
VisualStateGroupsetters are mutated in-place (e.g., a VisualState's SetterValueis changed), the framework does not reapply the visual state to the target element.VisualStateGroupListvalidates group/state name uniqueness onAdd()viaWatchAddList, but there is no mechanism to re-evaluate and reapply the current visual state after setter mutations.Motivation
Hot Reload scenarios (including XAML Incremental Hot Reload) need to update VSM setters in-place and have the changes reflected on the element. Currently there is no way to force reapplication of the current visual state without reconstructing the entire VisualStateGroup hierarchy.
Proposed API
Or an internal API if this should not be public.
Related