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!

WPF Text to Animated Path

Not sure what to call this - slate control? Or Text Scribbler? May be, or perhaps just "text to animated path control" :). Anyway, I was playing around with the possibility of animating text in such a way that you can see the text being written as though with a pen or a piece of chalk. This is the end result...

You can get the source here. Just run the application, enter any text in the TextBox, and hit the button to see the text being scribbled down in an animated fashion. You can also choose the Font Family, and the Foreground of the text from the combo boxes.

This is what the application does when the button is clicked:
1) The text from the TextBox is converted into a PathGeometry using the FormattedText class (System.Windows.Media namespace). You can specify the Font Family, Font Size etc. and get the corresponding path.

2) A MatrixAnimationUsingPath is applied on the pen (the red color object in the screen shot above). The PathGeometry property of this animation is set to the value obtained from Step 1).

3) At this point, the pen will animate over the path, but nothing will be scribbled down. While the pen is being animated, a timer runs concurrently with an interval in milliseconds. Whenever the timer ticks, the current position of the pen is calculated, and a small dot (ellipse) is drawn at that point. This gives you the illusion of text being continuously written down with the pen.

That's it! Enjoy scribbling!

(Note: The sample supports multi-line scribbling as well. To test this out, just set AcceptsReturn to true on the TextBox (you may also need to set IsDefault to False on the Start Button so that it does not interfere with the return key meant for the TextBox). Now if you enter multiple lines within the TextBox and start scribbling, you get multi-line scribbling !)

Source: Get it here.

Debugging Data Binding in WPF

What do you do when you suspect that a data binding is broken in your WPF application? Looking at the Output window for data binding exceptions can be helpful in many cases. However, there are cases where this does not help.

For example, below I have TextBox.Text bound to Slider.Value. But notice that the binding is OneWay.

<TextBox Text="{Binding ElementName=slider, Path=Value, Mode=OneWay}" Height="30" Width="100" Margin="10" />

<Slider Minimum="0" Maximum="100" Value="20" Margin="10" x:Name="slider" />

When I move the slider, the text in the TextBox shows the slider value as expected. Now I enter some text in the TextBox(which causes the binding to break since it is OneWay binding; but assume that I haven't realized that). I move the slider now, but the text in TextBox does not update. I suspect that the binding is broken. But how do I confirm that?

Simply looking at the Output Window in this case reveals nothing. What I've been doing until now is to add a dummy converter and set a break point in the Convert method. If the break point is not hit I know that the binding is broken. But that is really a long way of doing something that should be really done in a simpler way....

WPF 3.5 has a new property called PresentationTraceSources.TraceLevel that you can set on your data binding to get more detailed information on the binding in the Output Window. In fact, if you set the trace level to High you can get details on every step in the process of the binding.

So to the above code, I make two changes

• Add a namespace reference to System.Diagnostics
• Set PresentationTraceSources.TraceLevel=High on the binding I want to inspect.

<Window x:Class="DebugBindings.Window1"... xmlns:trace="clr-namespace:System.Diagnostics;assembly=WindowsBase">

<StackPanel>

<TextBox Text="{Binding ElementName=slider, Path=Value, Mode=OneWay, trace:PresentationTraceSources.TraceLevel=High}" Height="30" Width="100" Margin="10"/>

<Slider Minimum="0" Maximum="100" Value="20" Margin="10" x:Name="slider" />

StackPanel>

Window>

Now when I inspect the Output Window after running the application, I can see step-by-step details of the data binding process.

Created BindingExpression (hash=17654054) for Binding (hash=44624228)
Path: 'Value'
BindingExpression (hash=17654054): Default update trigger resolved to LostFocus
BindingExpression (hash=17654054): Attach to System.Windows.Controls.TextBox.Text (hash=52727599)
BindingExpression (hash=17654054): Resolving source
BindingExpression (hash=17654054): Found data context element: (OK)
Lookup name slider: queried TextBox (hash=52727599)
BindingExpression (hash=17654054): Resolve source deferred

BindingExpression (hash=17654054): Resolving source
BindingExpression (hash=17654054): Found data context element: (OK)
Lookup name slider: queried TextBox (hash=52727599)
BindingExpression (hash=17654054): Activate with root item Slider (hash=54371668)
BindingExpression (hash=17654054): At level 0 - for Slider.Value found accessor DependencyProperty(Value)
BindingExpression (hash=17654054): Replace item at level 0 with Slider (hash=54371668), using accessor DependencyProperty(Value)
BindingExpression (hash=17654054): GetValue at level 0 from Slider (hash=54371668) using DependencyProperty(Value): '20'
BindingExpression (hash=17654054): TransferValue - got raw value '20'
BindingExpression (hash=17654054): TransferValue - implicit converter produced '20'
BindingExpression (hash=17654054): TransferValue - using final value '20'

If I now enter text in the TextBox, I can check the Output Window to confirm that the binding was indeed broken!

BindingExpression (hash=17654054): Deactivate
BindingExpression (hash=17654054): Replace item at level 0 with {NullDataItem}
BindingExpression (hash=17654054): Detach

The only down side is that you have to manually add this property to each binding that you want to inspect.