Customizing The DependencyObject Inheritance Tree

Question

I'm struggling to find sufficient information about the property Inheritance Tree (or Inheritence Context) used by DependencyObject and DependencyProperty.

I would like to use the value inheritence capability of DependencyProperty outside of a typical WPF page, such that Object A is the logical parent Object B, and thus a value assigned to a property on Object A will automatically propogate to Object B unless it has been locally set (a bit like the FlowDirection property works in WPF).

If Object A and Object B are derieved from DependencyObject, and are not children of a UIElement (in other words, Object A is it's own root), then how do you establish the logical tree so that DependencyProperty understands that B is a child of A?

The Hillberg Freezable Trick as well as Josh Smith's bag of tricks aren't quite what I'm looking for. I don't want to retrieve properties from an existing element tree... I want to create my own, non-visual element tree... i.e. have control over the inheritence context.

Anyone know where this body of knowledge is hiding?

Center

I'm curious how you ended up solving your problem. Did you write your own tree/inheritance/DP mechanism? Find any libraries to help you on your way? I'm attempting to do something similar. – Cigarette

Answer 1

After much research and muddling through the source code for DependencyObject, here's the short answer:

The InheritenceContext (the property which reveals the logical parent of an instance) is (like 90% of the useful implementation of DependencyObject) marked as internal and thus kept hidden from all code outside of WindowsBase.dll

It is possible to use reflection to set the _contextParent field, as well as to call this hidden methods to set the InheritenceContext, but at the end of the day its not a clean solution.

After scouring the DependencyObject source code, I've gotta say that I'm not impressed. DependencyObject could and should have been a very clean, ubiquitous, reusable class. Instead it is structurally and behaviourly bound to it's inheritors, and even contains specific constants, fields, methods and work-arounds to help Freezable co-exist with the rest of the sub-classes, which not only strays far from good OO design, but also makes an otherwise superb class utterly unusable outside of the WPF framework.

Center

Cheers for the answer to this interesting question. It's a shame that these kinds of properties require a specific base class, though I can't think of a better solution shy of language/compiler support (same for Freezable). – Broadminded

Can you share the solution you went for ? You did your own "DependencyObject" implementation ? – Millian

Answer 2

I assume that you're asking about the propagation of values to children that do not override values themselves.

The concept of a WPF element having a child is introduced by ContentControl as far as I know. This comes into play much further down the hierarchy than you want to go. So, I would assume that if you were to simply derive from DependencyObject that this behaviour would not manifest.

Specifically, a child needs to know to ask its parent if it doesn't have a value for a given property.

Interesting question. I'd like to know the full answer too.

Broadminded