Implement a UI state machine using MVVM pattern

Question

I'm working on a state machine program with wpf as UI layer, I used this link: http://elijahm.ninjuro.com/2012/01/04/visual-states-in-wpf-4-0/#comment-312 article to change contents of active window by calling VisualStateManager.GoToState(,,).

but I'm not a good wpf developer and my problem is the last section of that article, section "Changing from one state to another" in where developer creates StateManager class and use it to change UI state. I don't know where in my code I mast use of StateManager and how to transmit business state changes to UI?

score 7 · Accepted Answer · edited May 23 '17 at 11:54

Good question. It looks like the author of that blog post does assume that you'll know where to put the code pieces that he shows, based partially on the names of classes and the use of bindings, etc. Also, if you haven't already, it will help to read up on the MVVM pattern so that the things that he references will make better sense.

Having said that, I'll provide a brief explanation of that section of the blog post. First, that "StateManager" class is analogous to the "StateHelper" class in this answer. That answer has a bit more explanation as well.

Essentially, we have three main pieces that we need to work together: The ViewModel, the View, and a custom attached property class (especially the changed callback method for this attached property).

The author created a property in his ViewModel (of type string) called "ViewState". The idea here is that, in his methodology at least, the ViewModel will know when a view state should be changed (i.e., in reaction to a certain change in data). So when that time comes, he will change the ViewModel's "ViewState" property to another state name (maybe "alertState" or something), using regular C# code - maybe something like:

this.ViewState = "alertState";

The thing that then ties this together is the fact that the View has a way of just binding (i.e., "listening to changes to") to those "state changes" - meaning that the view executes the state changes by listening to changes to the "ViewState" property of the ViewModel (not quite that simple, but I'll get there in a minute).

StateManager.VisualStateProperty = "{Binding Path=ViewState}"

And the way that it is able to execute the actual VisualStateManager state change is that the custom "StateManager.VisualStateProperty" attached property's changed callback method executes the built-in WPF method VisualStateManager.GoToState(...). In his post, this is the changed callback that I'm referrring to:

new PropertyMetadata((dependencyObject, args) =>
{
    var frameworkElement = dependencyObject as FrameworkElement;
    if (frameworkElement == null)
        return;
    VisualStateManager.GoToState(frameworkElement, (string)args.NewValue, true);
}));

So when the ViewModel changes its ViewState property, and since the View has a binding to that property, and since this custom attached property has been assigned the result of that binding, the binding engine changes the "result" of its binding, which causes the value of "StateManager.VisualStateProperty" to change, which causes the above changed callback method to fire, which (finally) causes the VisualStateManager.GoToState(..) method to execute the actual Visual State change.

score 1 · Answer 2 · answered Feb 06 '13 at 14:00

That article applies to the MVVM pattern, which separates logic code from the view and therefore requires extra code to redirect visual state changes from the ViewModel to the View. If you're not using MVVM then you can just do the state changes anywhere in your code-behind using VisualStateManager.GoToState:

VisualStateManager.GoToState(this, "MyNextState", true);

Implement a UI state machine using MVVM pattern

2 Answers2