好问题。看起来该博客文章的作者确实假设您会知道将他展示的代码片段放在哪里,部分基于类的名称和绑定的使用等。另外,如果您还没有,这将有助于阅读 MVVM 模式,以便他引用的内容更有意义。
话虽如此,我将简要解释博客文章的该部分。首先,“StateManager”类类似于此答案中的“StateHelper”类。该答案也有更多解释。
本质上,我们需要协同工作的三个主要部分:ViewModel、View 和自定义附加属性类(尤其是此附加属性的更改回调方法)。
作者在他的ViewModel(类型string
)中创建了一个名为“ViewState”的属性。这里的想法是,至少在他的方法论中,ViewModel 将知道何时应该更改视图状态(即,对数据的特定更改作出反应)。因此,当那个时候到来时,他将使用常规 C# 代码将 ViewModel 的“ViewState”属性更改为另一个状态名称(可能是“alertState”或其他名称) - 可能类似于:
this.ViewState = "alertState";
然后将其联系在一起的事实是,视图有一种方式binding
(即“监听更改”)那些“状态更改”——这意味着视图通过监听“状态更改”的更改来执行状态更改。 ViewModel 的 ViewState" 属性(不是那么简单,但我会在一分钟内到达那里)。
StateManager.VisualStateProperty = "{Binding Path=ViewState}"
它能够执行实际VisualStateManager状态更改的方式是自定义“StateManager.VisualStateProperty”附加属性的更改回调方法执行内置的WPF方法VisualStateManager.GoToState(...)
。在他的帖子中,这是我所指的更改后的回调:
new PropertyMetadata((dependencyObject, args) =>
{
var frameworkElement = dependencyObject as FrameworkElement;
if (frameworkElement == null)
return;
VisualStateManager.GoToState(frameworkElement, (string)args.NewValue, true);
}));
因此,当 ViewModel 更改其 ViewState 属性时,并且由于 View 具有与该属性的绑定,并且由于此自定义附加属性已分配了该绑定的结果,绑定引擎会更改其绑定的“结果”,这会导致“StateManager.VisualStateProperty”的值发生更改,这会导致上述更改后的回调方法触发,这(最终)会导致该VisualStateManager.GoToState(..)
方法执行实际的视觉状态更改。