다음을 통해 공유

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">

        <Grid>

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

                  <ContentPresenter/>

            </Border>

            </Grid>

            <ControlTemplate.Triggers>

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

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

                </Trigger>

            </ControlTemplate.Triggers>

        </ControlTemplate>

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

  • Anonymous
    May 27, 2008
    "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?

  • Anonymous
    May 27, 2008
    PingBack from http://dogs-pets.info/dog-breeding/?p=970

  • Anonymous
    May 27, 2008
    The condition could be an attached behavior...though in Silverlight it generally isn't.

  • Anonymous
    June 05, 2008
    The comment has been removed

  • Anonymous
    June 10, 2008
    Recently , I talked about how templates in WPF/SL are fundamentally built around the concept of a state

  • Anonymous
    June 18, 2008
    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?

  • Anonymous
    August 08, 2008
    As I’ve described before , we introduced the new VisualStateManager concept into Silverlight WPF before

  • Anonymous
    September 18, 2008
    The comment has been removed