RE: [aus-dotnet] WPF Dependency Properties!

[Paul Stovell]

Hi Winston

 

The hashtable exists on the DependencyObject, not on the DependencyProperty.

 

So, let's say you have a Button, and you set the Background property. The internal hash table might be like this:

 

      Button b;

      b._properties[Button.BackgroundProperty] = Brushes.Green;

 

Of course the "_properties" hashtable is private, so you use the public GetValue/SetValue methods:

 

      b.SetValue(Button.BackgroundProperty, Brushes.Green)

 

It works the same way for attached dependency properties, which is what makes them so powerful:

 

      b._properties[Grid.Left] = 35.00;

 

Since the hash table can store any old value it likes as the key.

 

Why are the values stored on the DependencyObjects, rather than the DependencyProperties? It comes down to memory management. If they were stored like this:

 

      Grid.Left._properties[b] = 37

 

Grid.Left, which is static (and so exists forever), would have a reference to the Button (which is just an instance). The button would never be garbage collected, because it has a root reference in the static object. So you'd be wasting memory terribly.

 

(Just out of interest...)

 

In a way this is unfortunate. If memory concerns weren’t an issue, we could store it differently. At the moment, things are stored like this:

 

                Object  ........ Has Properties->Values hashtable

 

We could store it like this:

 

                Property ...... Has Object->Values hashtable

 

This would allow the properties to be defined using generics, such as DependencyProperty<T>. They would be strongly-typed, and you'd avoid the badness of boxing. However with garbage collection being what it is, there's not a lot that can be done.  I did experiment with a version of generic DependencyProperties that used Weak References in .NET, but it introduced more overhead because of having to manage the references.  

 

One thing to remember from this is that the hash table for dependency properties/values is stored on each object as object : object. That means if you have integer, double or Boolean properties, and you animate them, you run the risk of a lot of boxing. I've seen people "pre-box" versions of values, like this:

 

static class BoxedBool {

    public readonly object True = true;
    public readonly object False = false;

}

 

Then they can assign values of true and false very quickly without incurring the extra boxing penalty.

 

Hope that explains things.

Regards,

Paul Stovell
Readify | Senior Developer
Microsoft MVP: Visual Developer - Client Application Development

M: +61 420 314 127 | C: paul.stovell@xxxxxxxxxxx | B: www.paulstovell.net

From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Winston Pang
Sent: Wednesday, 13 June 2007 8:43 AM
To: dotnet@xxxxxxxxxxx
Subject: [aus-dotnet] WPF Dependency Properties!

 

Hello everyone,

 

 

Alright i look like a complete idiot but i don't get it...

 

I've dugg through resources, and i've been reading WPF Unleashed.

 

 

I don't understand the concept of it too well, from what i've been reading, the DependencyProperty type is a static type you create, then you create a Property wrapper that calls the underlying GetValue and SetValue, and from what i read the storage is essentially like a Hashtable.

 

Does this mean that everytime we create an instance of say type Foo, and set the property Bar, all instances of Foo's, Bar value will be stored in the same static dependancy property variable?

 

Sorry, i think i've totally confused myself haha! If anyone else can explain it better, please help me out or point me to a good article.

 

 

Cheers,

 

 

Winston