我发现可视化状态管理器和触发器在功能上有一些重叠。
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="CommonStates">
<VisualState x:Name="Pressed">
... bla bla ...
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>或者我可以去
<Trigger Property="IsPressed" Value="true">
... bla bla ...
</Trigger>什么时候我应该使用一种而不是另一种?
发布于 2016-12-08 09:08:31
为什么使用VisualStateManager而(最终不是)使用触发器呢?
让我们从它们之间的一般区别开始。
的状态时,
触发时执行的触发器:
:通过
Setter建立其他触发器
- _VisualState_:
1. Initiates a status change request to `VisualStateManager`.
2. `VisualStateManager` performs a `VisualTransition` before setting the state.
3. `VisualTransition` performs a `Storyboard`.
4. When a time specified by `GeneratedDuration` (of `VisualTransition`) has passed, `VisualStateManager` updates the `CurrentState` property of the corresponding `VisualStateGroup` of the control.
5. Next, `VisualStateManager` performs the initial `VisualState` requested in (1).
6. And finally, `VisualState` performs another `Storyboard`.
是的,您认为VisualStateManager使场景比触发器更复杂,这是正确的。然而,VisualStateManager的复杂性允许程序员做触发器不能做的事情(不是以简单的方式):
VisualTransition.和To命令(例如停止一个转换动画并在transition).
甚至(这是最神奇的事情)不需要离开
VisualStateGroup),并且每个状态组在给定的时间有一个唯一的CurrentState。也许一张图片最能说明问题:
我很确定这样做有更多的好处。最有趣的是,如果你想自己使用触发器来实现这些优势,你最终会陷入一个非常类似于VisualStateManager的系统中……试试看!
然而..。总是使用VisualStateManager并不好
即使有了所有这些优点,触发器系统也不应该被VisualStateManager系统抛弃。触发器是一个更简单的系统,但它也有其潜力。
就我个人而言,我会为非常简单的“原始”控件使用触发器,这些控件不需要奇怪的行为或奇怪的动画。在这种类型的控件中,VisualStateManager的实现复杂性并不能证明使用它是合理的。
对于更复杂的控件,我会使用VisualStateManager,特别是那些使用其他“原始”控件的“复杂”控件(请注意“原始”和“复杂”概念的含义)。根据用户交互,这个控件自然会有一个复杂的行为。
发布于 2011-03-24 00:02:59
这两者之间有大量的重叠。VisualStateManager是在处理了在复杂场景中使用触发器可能产生的“痛苦”之后添加的。一般来说,它更灵活,更容易使用。
发布于 2011-03-24 00:15:07
有些事情用触发器更容易做,有些事情用VSM更容易做。
使用VSM的最大原因是Silverlight不支持触发器。如果您希望过渡到Silverlight,请远离触发器。
VSM有两个缺点:
不过,VSM似乎是未来的趋势。如果您使用的是Blend,则VSM的配置非常简单。
https://stackoverflow.com/questions/5408062
复制相似问题