New Silverlight Video Tutorial: How to Fire a Visual State based upon the value of a Boolean Variable

Hello All!

In this short 7.44 minute video I show you how you can, with one line of C# code fire one of two Visual States based upon the value of a Boolean variable, one if it is true or another one if it is false.  This is much easier than evaluating the variable yourself and then firing each VisualState manually.  Enjoy!


My Source Code:

    • Raj
    • May 20th, 2010

    Great Video as usual 🙂

  1. I’m not entirely sure who this video is aimed at (I’m assuming it’s not developers given the basic C# content), but that expression you’re using is a ternary expression.

    I’d probably take it a step further. If you have a naming convention for “bool based” states where you have a base state name followed by True or False such as:


    (Where the “base state name” is “BlobState”)

    You could then create a simple helper method along the lines on:

    public static bool GoToBoolState(Control control, string baseStateName, bool useTransitions, bool value)
    return VisualStateManager.GoToState(control, String.Format(“{0}{1}”, baseStateName, value), useTransitions);

    Which would make your click code cleaner, and only require you to pass in the base state name:

    void ChangeBtn_Click(object sender, RoutedEventArgs e)
    MyBool = !MyBool;

    VisualStateHelpers.GoToBoolState(this, “BlobState”, true, MyBool);

    (I’ve also collapsed the unnecessary if)

    • Jason
    • May 22nd, 2010

    I remain unconvinced that writing VSM code in anything other than a control is good practice.
    The state of the data behind a view belongs to that object, and it doesn’t make sense that the business coder should create ViewStates for everything that they imagine the UI designer will need.
    For example, if I create an Order class that I allow a UI to bind to the screen can bind to CustomerName, DeliveryAddress, IsPaidFor, etc, then does it make sense that I include ViewStates of ‘StateIsPaidFor’/’StateIsNotPaidFor’ and so on just in case the UI designer wants to make pretty things happen on the screen?

    I believe that as the VSM is part of the UI, *all* associations between model and UI should be through the bindings, and in the example shown it’s as simple as three lines of XAML:

    This short piece of code removes all dependencies and gives total customizability from within Blend. As a developer I don’t need to worry about what the guy with Jesus-sandals and and ponytail requires to do his UI magic, and it simplifies the underlying code.

    Am I alone in this thinking? Do most SL developers write code-behind and not use bindings?

    • Jason
    • May 22nd, 2010

    Not sure how you post XAML in here, so I’ve replaced the chevrons with square brackets:
    [ei:DataStateBehavior Binding=”{Binding IsPaidFor}” Value=”True” TrueState=”TrueState” FalseState=”FalseState”/]

    • Rajmund Rzepecki
    • May 29th, 2010

    Jason, you’re not alone. I second your thought about VSM belongs to UI and designers should rely on bindings and basic set of converters provided by developers like “BoolToVisibilityConverter” or “BoolToOpacityConverter”. Just make really 5-6 versions of those converters will take care of 90% of the common designer needs. I would say burden of declaring and handling Visual State “go to” logic is for something more complex (eg. animation, user interaction) than some plain projection from some bool value to the single property on the screen.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: