Dependency Property Factory – Part 3

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
        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 =
    public static readonly DependencyProperty ReadOnlyProperty =
    public static readonly DependencyProperty CallbackProperty =

    [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); }

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

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

    public static void OnChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )

    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.


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.

public class FactoryExample
    public string Standard { get; set; }

    public bool ReadOnly { get; private set; }

    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.

Author: Steven Jeuris

I have a PhD in Human-Computer Interaction and am currently working both as a software engineer at iMotions and as a postdoc at the Technical University of Denmark (DTU). This blend of research and development is the type of work which motivates and excites me the most. Currently, I am working on a distributed platform which enables researchers to conduct biometric research 'in the wild' (outside of the lab environment). I have almost 10 years of professional software development experience. Prior to academia, I worked for several years as a professional full-stack software developer at a game development company in Belgium: AIM Productions. I liked the work and colleagues at the company too much to give up entirely for further studies, so I decided to combine the two. In 2009 I started studying for my master in Game and Media Technology at the University of Utrecht in the Netherlands, from which I graduated in 2012.

One thought on “Dependency Property Factory – Part 3”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: