Monday, April 27, 2009

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.

Thursday, April 23, 2009

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.