Vincent Sibal's Blog : wpf 4.0

The Control Local Values Bug Solution and new WPF 4.0 related APIs

vinsibal — Thu, 21 May 2009 17:57:00 GMT

Intro

Previously I did a post on the “Control Local Values bug” and how a subtle bug can be introduced when setting dependency properties of controls to local values. In WPF 4.0 (dev10), a mechanism was added to the property engine to solve this problem. Here are the new APIs in dev10:

public class DependencyObject

{

// Sets the value of a dependency property without changing its value source.

public void SetCurrentValue(DependencyProperty dp, object value);
}

public struct ValueSource

{

public bool IsCurrent { get; }

}

Basically, when using DependencyObject.SetCurrentValue instead of DependencyObject.SetValue you set its effective value but its ValueSource remains the same. This is very similar to coercion.

Sample Test App

To make it more clear, I wrote a sample test app that shows the BaseValueSource and ValueSource properties when changing a DependencyProperty (DP) via SetCurrentValue. I created a custom control with a DP, TitleProperty, where I track its values. In addition, I setup several scenarios where the TitleProperty is initially set by a particular BaseValueSource. I’ll go through one scenario here.

I setup the custom control where the TitleProperty is set from a Style with a binding.

<Setter Property="Title"

Value="{Binding RelativeSource={RelativeSource Self},

Path=WorkingTag,

StringFormat='Set via Style w/ Binding: {0}'}" />

<Setter.Value>

<Button Content="{TemplateBinding Title}"

Background="{TemplateBinding Background}" />

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

<local:CustomControl x:Name="CustomControl_Style_Binding"

Style="{StaticResource StyleBindingCustomControlStyle}"/>

</GroupBox>

Initially it will look like this:

Notice the BaseValueSource is ‘Style’, IsExpression is ‘True’, and IsCurrent is ‘False’ as expected. After pressing the “Set Current Value” button the values will update accordingly:

Now the local value has updated to a new string that I set and IsCurrent has updated to ‘True’. Also notice that BaseValueSource and IsExpression have not changed which is also expected. If you press “Clear Local Value” the values will update back to their initial values. Now to bring back the original issue with the control local values bug, if you were to set or clear the local value any previous BaseValueSource would be overwritten and any expression lost. I have created other scenarios in the sample with different BaseValueSource behavior so you can understand how setting the current value behaves in those scenarios. Please be sure to check it out below.

Usage Recommendation

For a control developer, the general recommendation is to always use DependencyObject.SetCurrentValue over DependencyObject.SetValue in Control code. You’ll notice that our stock controls in the 4.0 framework have all been updated to use this API instead of setting the properties with local values.

Here is the sample app which works with VS 2010 beta 1.

VS 2010 and .NET Framework 4.0 Beta1 are out now!

vinsibal — Thu, 21 May 2009 17:54:00 GMT

As many of you probably already know, dev10 beta1 is available for public download. Some of the additions to Beta1 on the WPF Controls side include:

· MultiTouch

· EasingFunctions for animations

· DataGrid, Calendar, DatePicker, and VisualStateManager in PresentationFramework.dll

· New APIs to support the control local values bug

· And tons of bug fixes on the new controls as well as existing control and element services areas

I’ll be going over some of these new features in more depth so stay tuned!

The Control Local Values Bug!

vinsibal — Tue, 24 Mar 2009 23:06:00 GMT

Intro

WPF dependency properties are properties that are registered through the WPF property system. By registering with the property system, the property will be provided a set of services such as data binding, styling, change notifications, animation, expressions, invalidation, and coercion. What I will be discussing here is dynamic value resolution and the issue of setting local values in controls.

Background

A dependency property’s value is dependent on multiple providers where there is a level of precedence for each provider. The BaseValueSource enum captures these providers (with the first being the lowest precedence and last being the highest)

· Unknown

· Default

· Inherited

· ThemeStyle

· ThemeStyleTrigger

· Style

· TemplateTrigger

· StyleTrigger

· ImplicitStyleReference

· ParentTemplate

· PatentTemplateTrigger

· Local

In addition to these base value sources, the dependency property can also come from an expression, animation, or coercion (which the internal WPF code represents them as ModifiedValues). Note that ModifiedValues are mutually exclusive from BaseValueSource. For example you can have a value that is set locally and coerced at the same time.

So how does this relate to the control local values bug?

As a control author, dependency properties are the general mechanism to communicate the state and behavior of the control. They will be used in data binding scenarios, visual representation, interaction, etc. This means that you will possibly and most likely be setting values on your dependency properties internally as state changes about your control. So as you are setting new values to a dependency property that you own, you may not realize that you are introducing a very subtle bug relating to dynamic value resolution precedence. I’ll use an example to clarify.

The DatePicker control from WPFToolkit has a DP called IsDropDownOpen. It is used by the DatePicker control to update when the calendar popup opens and closes. It listens for a change event and sets the Popup.IsOpen accordingly.

private static void OnIsDropDownOpenChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

{

DatePicker dp = d as DatePicker;

Debug.Assert(dp != null);

bool newValue = (bool)e.NewValue;

if (dp._popUp != null && dp._popUp.IsOpen != newValue)

{

dp._popUp.IsOpen = newValue;

}

The Popup also listens for when it opens and closes and makes sure IsDropDownOpen is toggled to the correct state.

private void PopUp_Opened(object sender, EventArgs e)

{

if (!this.IsDropDownOpen)

{

this.IsDropDownOpen = true;

}

…

}

Notice the bug? The bug lies in PopUp_Opened when setting IsDropDownOpen to a local value. This really appears harmless and you probably won’t actually see the bug in action until you hand it over to the app developer who will actually set different value providers on your control DPs. The problem is that setting a DP locally as an internal operation in your control will trump any and all value providers set on that DP (as local is the highest precedence). That means that the app developer who uses your control and decides to put some fancy styles, binding, triggers, and all that goodness will find that it will stop working for some reason and not immediately know what caused it.

To further describe how this can occur, here is an example using that same DatePicker (note that this has already been fixed in later version of the toolkit).

<Window.Resources>

</Style>

</Window.Resources>

<Grid>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<toolkit:DatePicker Grid.Row="1"

Name="datePicker"

Style="{StaticResource DatePickerStyle}" />

</Grid>

I’ve setup a style on the DatePicker where I’ve bound a CheckBox.IsChecked DP to the DatePicker.IsDropDownOpen DP. If you click on the CheckBox, the popup opens as expected. If you take a look at the BaseValueSource on IsDropDownOpen it will read Style. However, as soon as you close the popup, the binding does not work anymore which is expected since a local value is set on IsDropDownOpen.

Summary

To make it really short and sweet, setting dependency properties to local values in internal operations of a control can lead to the dreaded control local values bug. I’m sure you’re next question is, how can this be prevented? Well, I will be doing a follow-up post on what has been added in dev10 to easily prevent this bug so stay tuned!

UPDATE: Check out the follow up post here.