Why doesn’t my WPF Trigger work? (... a peek into the Dependency Property evaluation process)

Imagine a simple situation where I have a blue rectangle:

<Grid>
  <Rectangle Height="200" Width="300" Fill="Blue"/>
</Grid>

Now when I do a mouse over the rectangle, I want the color to turn to red - simple! The obvious choice in WPF is to add a property trigger. So that’s what I do.

<Grid>
  <Grid.Resources>
    <Style TargetType="Rectangle" x:Key="rectStyle">
      <Style.Triggers>
        <Trigger Property="IsMouseOver" Value="True">
          <Setter Property="Fill" Value="Red" />
        </Trigger>
      </Style.Triggers>
    </Style>
  </Grid.Resources>
  <Rectangle Height="200" Width="300" Fill="Blue"
             Style="{StaticResource rectStyle}"/>
</Grid>

But it doesn’t work! What could be wrong? Perhaps the mouse over event isn’t firing on the rectangle for some reason? I debug the trigger using this cool technique and find that the trigger is firing alright. Then what on earth is the problem?

A closer look reveals the real issue. The culprit was the Fill="Blue" assignment! When evaluating the value of a dependency property, the dependency property system takes into consideration a few factors. The whole dependency property value evaluation process is shown below. Certain factors have priority over others as shown in Step 1 below.

Step 1: Determine Base Value
In the order of diminishing priority:
(a) Local Value
(b) Style triggers
(c) Template Triggers
(d) Style Setters
(e) Theme Style Triggers
(f) Theme Style Setters
(g) Inheritance
(h) Default Value

Step 2: Evaluate
– If Step 1 returns expression (DataBinding or DynamicResource), evaluate

Step 3: Apply Animation

Step 4: Coerce
- If CoerceValueCallback defined

Step 5: Validate
- If ValidateValueCallback defined

In the above example of the rectangle, the trigger (see Step 1b) that I set in the style, had lower priority when compared to the local value (see Step 1a), that is the Fill="Blue" assignment. That was the reason why the trigger value was ignored. So the result/output of Step 1 as far as the Fill property was concerned was the local value “Blue”. In this example, Steps 2-5 do not apply.

So how do I get my trigger to work? If I remove the local value assignment for Fill, and instead set that value within the style, then everything will work as expected because triggers (see Step 1b) have higher priority over style setters (see Step 1d).

<Grid>
  <Grid.Resources>
    <Style TargetType="Rectangle" x:Key="rectStyle">
      <Setter Property="Fill" Value="Blue" />
      <Style.Triggers>
        <Trigger Property="IsMouseOver" Value="True">
          <Setter Property="Fill" Value="Red" />
        </Trigger>
      </Style.Triggers>
    </Style>
  </Grid.Resources>
  <Rectangle Height="200" Width="300"
             Style="{StaticResource rectStyle}"/>
</Grid>

Now the trigger works as expected!

Differences between the WPF and Silverlight 2 model

What are the differences between the WPF and Silverlight 2 model? If you have worked with WPF before you started working with Silverlight (like me!), then this is no doubt a key question lingering in your mind. I understand that Microsoft is planning to publish such a list, and that would be great when it comes. But until that is published, below is a list of differences that I have picked so far. Remember this is a comparision between WPF and Silverlight 2 Beta 1. Some of the gaps between these two related technologies may be filled in future releases of Silverlight.

The observations below are what apply to Silverlight 2 Beta 1.

Styles

• Once you apply a style to a FrameworkElement, you cannot reassign a new style. This is bad news because this means that the user cannot pick a theme. Having said that, you can still reassign properties that have been once assigned. This means that you can reassign the control template since it is a property as well.
• Styles cannot inherit from other styles - the 'BasedOn' property cannot be used.
• Styles have to be referenced by a key. This means that you cannot drop a style for a button in your 'application.resources' hoping that all buttons in the application will pick up the style. You need to explicitly reference it by its key in all buttons in the application. Sigh!

Triggers

See my earlier post on this. There are no triggers in Silverlight Beta 1 for styles, control templates and data templates. Sigh, sigh and more sigh!

Say you are changing the control template of a button. When doing that, as part of the template you would want to define an animation that should fire when the mouse is over it. In WPF, you would just add a trigger in the control template that looks for the IsMouseOver property - which is a neat way of doing things. But in Silverlight, the developer who creates the control has to create event handlers for the MouseEnter and MouseLeave events, and in these event handlers he has to load storyboards with well known names. Then hope that the designer/developer skinning the control will supply storyboards with the same names!

Control Templates

Keeping aside the limitation control templates have that I explained above (in the triggers section), I think this is one area that Silverlight is better than WPF. Silverlight follows the parts model. This means that any control (controls that ship with Silverlight and custom controls) publish a well defined control contract. This control contract will define

1. the minimum UIElements (and their names) that should be present in a control template for that control
2. the storyboards (and their names) that should be present.

So this means that a designer/developer who is going to skin (or define a new control template for) the control needs to only look at the control contract to understand what the control expects to function properly.

In WPF, you have to search for the "PART_" prefix in the default control template. There is no well-defined control contract. I understand from the MIX talks that this is one area that WPF, the big brother, will listen to Silverlight and emulate it in future WPF releases.

Also, a custom control in Silverlight cannot inherit from UIElement or FrameworkElement classes though these classes are present (by the way, there is no Visual class in the class hierarchy in Silverlight). Custom controls should extend the Control class, or other classes like TextBox or Button that extend the Control class.

What makes skinning a control (read changing its control template) really complicated now is that at the moment Blend does not support templating. I'm sure that is coming. But until then, your XAML editing skills will be put to the test!

Resources

Dynamic resource references are not available. All are static references.

Data Binding

The following apply to Silverlight 2 Beta 1:

• No binding the property of a UI control to the property of another UI control. There is no 'ElementName' property in the binding syntax.
• No 'RelativeSource'
• No 'OneWayToSource' - who needed it anyway?
• No UpdateSourceTrigger property. All updates to the source (for two way binding) happen immediately, except in the case of TextBox in which case changes are propogated to the source when the focus is lost.
• Cannot bind directly to XML data. Need to convert the XML to CLR objects, and then bind to the CLR object.
• No ReadOnlyObservableCollection. Fortunately, the ObservableCollection is available which is more important.
• No CollectionView for sorting and filtering.
• No validation rules.
• No DataTemplateSelector for dynamically selecting data templates based on data.
• No XMLDataProvider and ObjectDataProvider.

Commanding

• Commands and input bindings are not available in Silverlight 2 Beta 1.

These are a few things I observed about Silverlight 2. I plan to keep this list updated so that this will be a ready reference for someone looking for the differences between the WPF and Silverlight 2 model.

No Triggers in Silverlight 2 Beta!

Being a WPF developer, I have been hoping that the Silverlight model would resemble WPF closely. After all, Silverlight is supposed to be a 'subset' of WPF (remember the code name for Silverlight was WPF/E - 'WPF Everywhere').

Now that Silverlight 2 Beta is out, I have been looking at it very closely. As expected a lot of features are common to WPF - styles, templates, databinding etc. But what on earth happened to triggers? Triggers are missing! C'mon Microsoft don't tell us there are no triggers in Silverlight. I'm hoping that triggers will arrive before the final release of Silverlight.

By the way, let me clarify that when I say that there are no triggers in Silverlight 2 Beta 1 what I mean is no triggers where they matter most - in styles, control templates and data templates. The FrameworkElement class does have a trigger collection, but that is not very useful is it, without triggers in styles and templates?

Update: For a full discussion on the differences between the WPF and Silverlight 2 model, see this post.

Also enjoy this geeky duel on the new Silverlight templating model (sans triggers) between two of my esteemed colleagues at IdentityMine - Robby Ingebretsen and Dr. WPF.