良い質問。そのブログ投稿の作成者は、クラスの名前やバインディングの使用などに部分的に基づいて、彼が示すコード部分をどこに配置するかを知っていると想定しているようです。また、まだの場合は、彼が参照するものがより理解できるように、MVVMパターンを理解するのに役立ちます。
そうは言っても、ブログ投稿のそのセクションについて簡単に説明します。まず、その「StateManager」クラスは、この回答の「StateHelper」クラスに類似しています。その答えにはもう少し説明があります。
基本的に、一緒に作業する必要がある3つの主要な部分があります。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プロパティを変更し、ビューにそのプロパティへのバインディングがあり、このカスタムアタッチされたプロパティにそのバインディングの結果が割り当てられているため、バインディングエンジンはそのバインディングの「結果」を変更します。 「StateManager.VisualStateProperty」の値が変更されます。これにより、上記の変更されたコールバックメソッドが起動し、(最終的に)VisualStateManager.GoToState(..)
メソッドが実際のビジュアル状態の変更を実行します。