This post is a second follow-up to an earlier attempt to simplify creating dependency properties. In the previous follow-up I discussed unanswered questions about the WPF dependency property system which prevented me from continuing the implementation.

First of all, I would like to thank Einar Ingebrigtsen for helping me out on some of the following issues. He has a solution of his own inside the open source Balder project.

The answers to the questions:

“Does anyone know concrete examples of problems caused by not following the convention of naming the CLR property wrapper the same as the dependency property, or in other words, why is it of any importance?”

External tools may use this convention to access the dependency properties. I would argue these tools could be made smart enough to solve this without the convention, but since my proposed solution doesn’t require passing this name anymore at all, this is not an issue anymore.

“Why can I still use the dependency properties through XAML, without adding the field identifiers that end with the suffix ‘Property’?”

The XAML processor doesn’t use these identifiers directly, as the documentation on msdn might make you believe. However, again external tools, or future versions may follow this convention, so let’s assume it is required. Since I don’t own/use any of these tools I can’t verify this. Of real importance is the necessity for the properties to be registered in a static context. Luckily this makes the factory approach still a viable option.

The solution!

Taking all this new information into consideration, this is the best I could come up with:

public class FactoryExample : DependencyObject
{
    public enum Property
    {
        Standard,
        ReadOnly,   // This becomes a readonly property.
        Callback    // This property has callbacks assigned to it.
    }
    private static readonly DependencyPropertyFactory<Property> m_properties =
        new DependencyPropertyFactory<Property>();

    public static readonly DependencyProperty StandardProperty =
        m_properties[Property.Standard];
    public static readonly DependencyProperty ReadOnlyProperty =
        m_properties[Property.ReadOnly];
    public static readonly DependencyProperty CallbackProperty =
        m_properties[Property.Callback];

    [DependencyProperty(Property.Standard, DefaultValue="foo")]
    public string Standard
    {
        get { return m_properties.GetValue(this, Property.Standard) as string; }
        set { m_properties.SetValue(this, Property.Standard, value); }
    }

    [DependencyProperty(Property.ReadOnly)]
    public bool ReadOnly
    {
        get { return (bool)m_properties.GetValue(this, Property.ReadOnly); }
        private set { m_properties.SetValue(this, Property.ReadOnly, value); }
    }

    [DependencyProperty(Property.Callback)]
    public int Callback
    {
        get { return (int)m_properties.GetValue(this, Property.Callback); }
        set { m_properties.SetValue(this, Property.Callback, value); }
    }

    [DependencyPropertyChanged(Property.Callback)]
    public static void OnChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
    {
        ...
    }

    [DependencyPropertyCoerce(Property.Callback)]
    public static object OnCoerce( DependencyObject d, object value )
    {
        ...
    }
}

As you might notice, not too many things have changed since the first post, but besides the advantages mentioned earlier, there are a couple of new features.

• The owner type for the factory is automatically set to the outer class of the passed template parameter. You can still pass the type manually.
• Exceptions are (optionally) thrown when the conventions aren’t followed. Thanks to the exceptions I actually found out one of my CLR property wrappers was set to protected (public is required), indicating a design flaw.
• Behaviour of get and set is encapsulated inside the factory. (E.g. No need to know whether a dependency property is read only when using a private setter.)
• Safe for obfuscation. (Before ID.ToString() was used, where ID was the enum value. Now the property name is used and the enum value is solely used to link things together.)

If you are anything like me, looking at the code you might think “This can still be improved!“. Unfortunately it looks like we reached the limitations of C#. What follows are some failed ideas I considered.

Requirement for an enum:

Why specify an enum, right? We already have the properties, why not use those as ID’s? In Einar’s implementation an expression tree is used as a way to represent the property by using a lambda expression, returning the property itself. (E.g. o => o.Standard) Unfortunately, expression trees can’t be passed as an argument to Attributes, required by the factory. Why? My guess is, “No particular reason.”

AbstractDependencyObject:

Why not have an abstract class implement the factory by default? A default GetValue() and SetValue() method could be added, so “m_properties.GetValue(this, Property.Standard)” would be reduced to “GetValue(Property.Standard)”. Such an implementation would quickly turn out unusable as multiple inheritance isn’t supported.

Every property has almost the exact same implementation!:

Although macros can be nasty, I’d argue this would be a correct usage for them. But, ofcourse C# doesn’t support macros. The duplicate code was there before, at least it’s reduced and grouped together now.

So it looks like this is the end, …. or is it? Enter, Aspect Oriented Programming!

At first, a strangely unfamiliar name to me. Now, I can only dream of the following implementation.

[DependencyObject]
public class FactoryExample
{
    [DependencyProperty(DefaultValue="foo")]
    public string Standard { get; set; }

    [DependencyProperty]
    public bool ReadOnly { get; private set; }

    [DependencyProperty]
    public int Callback { get; set; }

    ...
}

By acquiring a license for PostSharp, or with a lot of free time on your hands by implementing it yourself, you could attempt an implementation just like that! If it whet your appetite, be sure to check it out, but for me, the road ends here.

Dependency Property Factory source code

For the latest version of this code, you can download my FCL Extension library. It’s located in the Whathecode.PresentationFramework assembly under the namespace Whathecode.System.Windows.DependencyPropertyFactory.

This post is a follow-up to an earlier attempt to simplify creating dependency properties.

I didn’t notice a possible problem with the approach of the previous post since it doesn’t cause any problems in the project I use it in. WPF is quite strict when it comes to creating custom dependency properties. There are several ways in which you can do it wrong, and the code in the last post does admittedly, exactly that. “There are established naming conventions regarding dependency properties that you must follow in all but exceptional circumstances.” In my opinion, the ability to misuse an interface, and additionally not even being able to notice it, indicates a design flaw. To quote someone with a lot more experience:

Make interfaces easy to use correctly and hard to use incorrectly. The best way to prevent incorrect use is to make such use impossible. – Scott Meyers

…, and that’s exactly what I’ll try to do.

Convention 1: “The name of the field is always the name of the property, with the suffix Property appended.”

public static readonly DependencyProperty IsSpinningProperty =
    DependencyProperty.Register(
    "IsSpinning", typeof(Boolean), typeof(OwnerType));

Convention 2: “Define a CLR “wrapper” property whose name matches the name of the dependency property.”

public bool IsSpinning
{
    get { return (bool)GetValue(IsSpinningProperty); }
    set { SetValue(IsSpinningProperty, value); }
}

Convention 3: “In all but exceptional circumstances, your wrapper implementations should perform only the GetValue and SetValue actions, respectively.”

First I want to determine why ignoring these conventions causes problems. I was already aware that XAML bypasses property wrappers, resulting in convention 3, and proposed a solution in the previous post. An exception could be thrown in the factory class to prevent a wrong CLR property wrapper. Apparently XAML bypasses the wrappers by calling GetValue() and SetValue() directly (for performance reasons), using the property name with “Property” suffixed to it as a parameter. E.g. the property with the name “ABC” gets called as GetValue(ABCProperty). This causes convention 1. Convention 2 is a bit vague and not mentioned explicitly why it is necessary. Other problems when not following these conventions are according to msdn:

• Certain aspects of styles and templates will not work.
• Most tools and designers must rely on the naming conventions to properly serialize XAML, or to provide designer environment assistance at a per-property level.

Does anyone know concrete examples of problems caused by not following convention 2, or in other words, why is it of any importance?

The factory class mentioned in the previous post doesn’t follow convention 1 at all. Why can I still use the dependency properties through XAML? The setter and binding in the following sample work perfectly. It seems like all XAML really needs is the name of the dependency property as passed with the DependencyProperty.Register() method. This would also make a lot more sense, since the name would be redundant otherwise.

<DependencyPropertyTestControl
    XamlSetTest="100"
    Margin="{Binding RelativeSource={RelativeSource Self},
    Path=XamlSetTest}" />

    public class DependencyPropertyTestControl : Label
    {
        public enum Property
        {
            XamlSetTest
        }
        private static readonly DependencyPropertyFactory<Property> m_properties =
            new DependencyPropertyFactory<Property>( typeof( DependencyPropertyTestControl ) );

        public static readonly Dictionary<Property, DependencyProperty> Properties =
            m_properties.Properties;

        [DependencyPropertyAttribute( Property.XamlSetTest )]
        public string XamlSetTest
        {
            get { return GetValue( Properties[ Property.XamlSetTest ] ) as string; }
            set { SetValue( Properties[ Property.XamlSetTest ], value ); }
        }

        [DependencyPropertyChangedAttribute( Property.XamlSetTest )]
        public static void OnSourceChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
        {
            var control = d as DependencyPropertyTestControl;

            if ( control != null )
            {
                control.Content = e.NewValue;
            }
        }
    }

UPDATE:
I posted these questions on the msdn forum to see whether somebody could answer them. The answer seems to confirm my suspicions that the property system only uses the name passed to Register() and not the field identifier. I’m guessing it can access the dictionary of DependencyObject directly and uses the dependency property name as the key to find the property in this dictionary. Still it is not wise to break conventions, so I’ll attempt to adjust the factory so that it enforces them instead. I’m afraid this will make a lot of its code superfluous. Perhaps a helper class is a better approach. Recently I discovered exactly such an implementation, and will check it out.

If you have ever developed an application using WPF, you most likely came across dependency properties. At first you love the flexibility of them and what it allows you to do, as they are great! However, after a while you might feel like you are writing a lot of duplicate code, and are filling up entire classes with it. This for me was a strong indication to encapsulate the behaviour and creation of dependency properties as good software design calls for.

To get a quick idea of my proposed solution I’ll simply post two code segments. One taken from an excellent tutorial on dependency properties by Christian Mosers. The other adjusts the code segment using the new approach.

Most common usage:

// Dependency Property
public static readonly DependencyProperty CurrentTimeProperty =
    DependencyProperty.Register(
        "CurrentTime",
        typeof(DateTime),
        typeof(MyClockControl),
        new FrameworkPropertyMetadata(
            DateTime.Now, OnCurrentTimePropertyChanged, OnCoerceTimeProperty
        ));

// .NET Property wrapper
public DateTime CurrentTime
{
    get { return (DateTime)GetValue(CurrentTimeProperty); }
    set { SetValue(CurrentTimeProperty, value); }
}

private static void OnCurrentTimePropertyChanged(
    DependencyObject source,
    DependencyPropertyChangedEventArgs e)
{
    MyClockControl control = source as MyClockControl;
    DateTime time = (DateTime)e.NewValue;
    // Put some update logic here...
}

private static object OnCoerceTimeProperty(DependencyObject sender, object data)
{
    if ((DateTime)data > DateTime.Now)
    {
        data = DateTime.Now;
    }
    return data;
}

// Register the private key to set the value
private static readonly DependencyPropertyKey IsMouseOverPropertyKey =
    DependencyProperty.RegisterReadOnly(
        "IsMouseOver",
        typeof(bool),
        typeof(MyClass),
        new FrameworkPropertyMetadata(false));

// Register the public property to get the value
public static readonly DependencyProperty IsMouseoverProperty =
    IsMouseOverPropertyKey.DependencyProperty;

// .NET Property wrapper
public int IsMouseOver
{
   get { return (bool)GetValue(IsMouseOverProperty); }
   private set { SetValue(IsMouseOverProperty, value); }
}

My proposed solution:

// Enum declaring all the dependency properties present.
public enum Property
{
    CurrentTime,
    IsMouseOver
}

// A factory class used to create and manage the dependency properties.
private static readonly DependencyPropertyFactory<Property> m_properties =
    new DependencyPropertyFactory<Property>(typeof(MyClockControl));

// Public dictionary used to access the dependency properties.
public static readonly Dictionary<Property, DependencyProperty> Properties =
    m_properties.Properties;

[DependencyPropertyAttribute(Property.CurrentTime, DefaultValue=DateTime.Now)]
public DateTime CurrentTime
{
    get { return (DateTime)GetValue(Properties[Property.CurrentTime]); }
    set { SetValue(Properties[Property.CurrentTime], value); }
}

[DependencyPropertyChangedAttribute(Property.CurrentTime)]
private static void OnCurrentTimePropertyChanged(
    DependencyObject source,
    DependencyPropertyChangedEventArgs e)
{
    MyClockControl control = source as MyClockControl;
    DateTime time = (DateTime)e.NewValue;
    // Put some update logic here...
}

[DependencyPropertyCoerceAttribute(Property.DateTime)]
private static object OnCoerceTimeProperty(DependencyObject sender, object data)
{
    if ((DateTime)data > DateTime.Now)
    {
        data = DateTime.Now;
    }
    return data;
}

[DependencyPropertyAttribute(Property.IsMouseOver)]
public bool IsMouseOver
{
   get { return (bool)GetValue(Properties[Property.IsMouseOver]); }
   private set {
       m_properties.SetReadOnlyProperty(this, Properties[Property.IsMouseOver], value);
   }
}

As you might notice, the last code sample has a few advantages.

• To identify the dependency property an enum is used, still allowing for strong typed identification of the properties.
• By passing the owner type for the dependency property to the factory class, it is specified in just one place.
• The settings for a dependency property are placed right above the property which is used in code internally. Parameters you had to pass manually to the DependencyProperty.Register() method before are deduced automatically. You can still specify them manually as well.
• Although not really visible through this short code sample, adding more properties is really easy and requires a lot less code.
• Centralized code. In the unlikely event that the Register() method changes, you only have to adjust the code of the factory class.

How it works:
The factory uses reflection to analyse the code to which the attributes are applied. This way it knows the property type and whether the dependency property should be readonly or not. As a name for the property, the ToString() method is used by default.

To be fair I’ll also mention the problems I see with this approach:

• There is a small overhead to retrieve the dependency property through the Dictionary every time. I do believe this will have a minor impact.
• Since DependencyObject internally already works with a dictionary, it’s kind of a double effort.
• The enum value needs to be defined three times for every property. I don’t know an immediate solution for this, but it is relevant for a future post where I’ll discuss data model generation.

Possible expansions:

• Right now the Dictionary used to make the properties available for public use isn’t read only. Since this class isn’t available by default this might be a subject I’ll address at a later time. Googling for a short amount of time already indicated this is a known problem. Perhaps a custom implementation of Collection can be created to break all references to DependencyProperty.
• Because the factory controls the creation of the dependency properties, exceptions can be thrown when invalid usage is detected. E.g. When the .NET properties contain more statements than the GetValue() and SetValue().

All things considered I don’t see any major disadvantages, but I’m no WPF expert. I’d love to have some input from people more experienced with WPF.

Factory source code

UPDATE:

Possible problems due to WPF’s naming conventions are discussed in a new post.
For the most recent version, go to my last post for information. For the source code, you can download my FCL Extension library. The DependencyPropertyFactory is located in the Whathecode.PresentationFramework assembly under the namespace Whathecode.System.Windows.DependencyPropertyFactory.