Visual States in XAML Templates

The Silverlight and desktop WPF implementations of Templates use the same syntax and programming model for describing the tree of objects that make up the control body, but differ in how they describe dynamic changes of the template.  In desktop WPF, this is done using Triggers...for example, a trivial Button Template might look like:

        <ControlTemplate x:Key="MyButton" TargetType="Button">


                  <Border x:Name="Back" Background="{TemplateBinding Background}">





                <Trigger Property="IsMouseOver" Value="true">

                    <Setter Property="Background" TargetName="Back" Value="Red"/>




As I've explained in previous posts, time and resource constraints left us unable to implement Triggers in the Silverlight 2 timeframe.  We were left then with the problem of delivering the same functionality reusing as much existing code from Silverlight as possible.  The design we came up with evolved from deconstructing Triggers in WPF and thinking about the basic pattern anew.  The fundamental recognition is that a Trigger actually has two parts:  a condition (IsMouseOver == true) and a body (the Setters and other actions in more complex examples). 

The body of the Trigger changes the appearance of the Control...this is what we call a Control State, or a Visual State.  The latter term is more precise, as the Control also has a Logical State which consists of the values of all its properties.  The Condition in a Trigger maps the Logical State (IsMouseOver) to a Visual State (Background = Red). 

In Silverlight we had two existing, fully implemented things we could use to describe Visual States...a collection of Setters like a Style, or a Storyboard.  Since Storyboards allow you to create Visual States that are animated, we choose the second, more flexible construct.  The Condition we left to the Control code itself...and thus we get the Silverlight Beta 1 "Parts and States" model (Parts are an already existing concept from desktop WPF).   Looking forward to unification of the desktop and web Template models, we can imagine a world where a Trigger in the Template contains a GoToState action that triggers the Storyboard instead of the boilerplate code each control must currently write. 

In Silverlight Beta 2, we have taken some steps in that direction, and formalized the concept of a Visual State.  More soon.

Comments (8)

  1. joewood says:

    "the condition we left the control code itself".

    Is that (or could that) be via an attached behavior?  Or do you mean for each state property there will be a storyboard property that is fired when the value changes?

  2. JohnGossman says:

    The condition could be an attached behavior…though in Silverlight it generally isn’t.

  3. JoeS says:

    I’ve seen some of the recent blogs from some ms people talking about the upcoming release of silverlight beta 2. While I can say I look forward to a lot of things you have added/addressed, the whole concept of a visual state manager seems like a hack to me. So first we had the parts model, which I assume is still there, now we have a visual state manager, in wpf we have triggers, where will this end? Is it the end of the way we template controls in WPF? Will the VSM be the preferred way in WPF and Silverlight? Are there now going to be 4 things to think about when designing controls in both frameworks, Triggers, VSM, Parts Model, Transitions? Are you guys planning to introduce more new ways to do this kind of stuff in V next? I still don’t understand what was wrong with how it was done in WPF and why not try to keep to one model. How you do not plan to have a basic WPF feature like triggers in a so called subset of WPF is beyond me, but hey, I understand some things just are not possible and need to be cut. This would have been on the top of my list from the start though. Anyway, I’m not trying to be a downer on Silverlight, I’m actually very interested in it. My concern is with code reuse and maintenance. It’s great that Silverlight and WPF both use .Net and in that it is great and easy for people to jump back and forth, but when you have all of these ways to do the same things when it comes down to controls, it just seems unnecessary and confusing, especially people new to WPF/Silverlight.

  4. Recently , I talked about how templates in WPF/SL are fundamentally built around the concept of a state

  5. Neil Mosafi says:

    Fantastic, I just stumbled across this blog post and it answers a lot of the questions I had around this unification of templating in WPF and XAML.

    Ignore the complaints!  People forget that WPF and especially Silverlight are still in early development and are basically at v1.  Templating controls in WPF can become very complicated and it’s not at all "intention revealing" when you read a template with 10s of triggers all combined with multitriggers etc. Triggers->Named States Changes->Visual Tree Changes makes complete sense to me!  You have the right to change the model, especially when it simplifies things.

    So I assume that this is the way you will do state transitions in DataTemplates in Silverlight?

  6. As I’ve described before , we introduced the new VisualStateManager concept into Silverlight WPF before

  7. VisualStateManager, a.k.a. VSM, I quote our WPF architect John Gossman’s words from the architectural

Skip to main content