WPFとSilverlightのVisualStateMangerは実装が異なる
VisualStateManager for desktop WPF – Tales from the Smart Client
Furthermore, the normal pattern for using Silverlight controls with VisualStateManager is to have the controls call GoToState() in their implementation code. But desktop WPF controls do not have these GoToState() calls. The solution is to create VisualStateBehaviors that use the Attached Behavior pattern again to inject the GoToState() calls in response to the proper events. Take a look in the Behaviors folder of the VisualStateManager project to see how this works. It includes the abilities to write your own VisualStateBehaviors to add VSM support into any control *without* modifying the control itself.
ここでのVisualStateMangerはControlTemplate内で使用されるパターンに限定します。
SilverlightのVisualStateManagerは、コントロールの実装コードの中に各ステートを呼び出すGoToStateメソッドが存在しています。つまりコントロールの各イベントハンドラ内でそれに合わせたStateが適用されるようGoToStateメソッドが呼び出されるというようなイメージです。
ところがWPFのVisualStateManagerの場合、コントロール側ではGoToStateメソッドを呼び出す必要はありません。VisualSatateManger側で各イベントに対してGoToStateメソッドが注入されるような実装になっているためです。これにより、現在のWPFコントロールの実装を全く変更することなく、VisualStateMangerをサポートすることが可能となっています。
以前の投稿で、ClickイベントハンドラにてGoToStateメソッドを呼び出すようなサンプルをご紹介しましたが、これは間違いで実際にはGoToStateメソッドは必要ありません。これを呼び出さずともCommonStatesグループのPressedステートは、自動的に適用されます。
ですので、WPF ToolkitのVisualStateManagerを使えば、現在のWPF 3.5 SP1のコントロールでも、Silverlight向けに作成されたControlTemplateがほぼそのまま使用できるということになります。実際に下記のページで公開されているテーマは、多くがSilverlightで存在していたControlTemplateになっており、WPF ToolkitのVisualStateManagerを使った状態での適用が可能となっているものです。
つまり、VisualStateMangerをTriggerに書き換えるというような変更は行っていません。
ただし、あくまでこれは現在のWPF Toolkitでの実装であり、将来のWPF4ではどうなるのかは分かりません。
