This blog attempts to be a collection of how-to examples in the Microsoft software stack - things that may take forever to find out, especially for the beginner. I see it as my way to return something to the Microsoft community in exchange for what I learned from it.

03 May 2010

Recently I tried to make my first attached dependency property and it struck me as odd that I could find a lot of articles on dependency properties – but it still took me quite some time to piece together the how and the why. And basically they all parrot the same few samples. So I decided to try my own take on the subject.

So what is an attached dependency property, then?

It helped me a lot to think of an attached dependency property as being the property equivalent of an extension method. You basically attach a new property to an existing object. Without actually modifying the object definition.

What is it good for?

About the same as an extension method: you can add extra properties to existing objects, without having to go trough the hoopla of inheritance. Which is especially handy when inheritance is not possible, like in sealed objects. More importantly, these properties can play along in the WPF en Silverlight data binding. The most important application, as far as I am concerned, is that you can make something bindable that is not bindable out of the box. If some value(s) a GUI component can only be set by a method, you cannot use it from MVVM, for example. By making an attached dependency property that passes on the new value to said method you work around that. See below for how you make such a callback.

In fact, attached dependency properties is part of the magic of that makes Laurent Bugnion’s MVVM Light toolkit go, at least where the ButtonBaseExtensions class is concerned, and reading the code in this class actually (and finally) made the penny drop for me.

So how do you make an attached dependency property?

You make a static class, in which the property is declared and 'hosted', as I call it. The general form is like this:

The whole thing works by naming convention. So if you call your property "MyPropertyName", then:

Your DependecyProperty needs to be called MyPropertyNameProperty

Your Set method needs to be called SetMyPropertyName

Your Get method needs to be called GetMyPropertyName

When you register your property the way I do, the members in the RegisterAttached method call are, from left to right:

The name of your property (as a string, yes)

Property value type (here “TargetPropertyType”, but of course that can be anything)

Type of the hosting class (i.e. DependencyPropertyHoster in this case)

Callbackmethod to be called when the property is changed.

How do you use it from XAML?

First, you need to declare its namespace and possibly its assembly. Suppose my class DependencyPropertyHoster was in namespace LocalJoost.Binders, and in a separate assembly called LocalJoost, I would need to declare it as

xmlns:MyPrefix="clr-namespace:LocalJoost.Binders;assembly=LocalJoost"

and if you want to use it in binding, you use

MyPrefix:DependencyPropertyHoster.MyPropertyName="{Binding whatever}"

I am currently making a small mapping application using a MultiScaleImage for showing Bing Maps that heavily depends on this trickery. Stay tuned, an example of this will probably follow shortly.

But wait, where is the actual data stored if not in the object itself?

To be honest, I don’t really know. An explanation is provided in the first comment by Dennis Vroegop (thanky you!). But to be even more honest, for now I don’t really have to know. If it works, it works. That's the real beauty of abstraction :-)

Update: for the real lazybones, a code snippet

Unzip this file in your code snippet directory. You will find this in Libraries\Documents\Visual Studio 2010\Code Snippets\Visual C#\My Code Snippets. From now on, if you type “adp” followed by a tab it will automatically insert an attached dependency property for you

Feedback, comments and tokens of appreciation

If you spot things that are incorrect, or if you don't understand what I mean, please drop a comment on the offending article and I will help you ASAP. You can e-mail me at joostvanschaik at outlook dot com or contact me via twitter.

If you find the information on this blog useful (and apparently some 600+ people per day do on average) please let me know as well, that encourages me to keep doing this. Or do tell others - that made me an MVP; who knows what more it might bring ;-P

Disclaimer and legal stuff

Although I take great care in providing quality samples, all postings, articles and/or files on this site are provided "AS IS" with no warranties, and confer no rights. The views expressed on this blog are strictly my own and do not necessarily reflect the views of my employer, or anyone else on the planet for that matter.

I usually make original content, sometimes building upon other people's work. Sometimes I explain things that can be found elsewhere because I felt what I read was not clear enough for my limited mind so I explain it the way it finally clicked with me. In all cases I take great pains to be sure to link to people or articles who deserve the credit. If you think I have shortchanged you on the credits please let me know.

Please note, I do not work for Microsoft and while I proudly wear the title of "Microsoft Most Valueable Professional", my opinions, files offered, etc. do not represent, are approved of, endorsed by or paid for by Microsoft. The only power behind it is me and my sometimes runaway passion for parts of Microsoft's technology.