.netwpfdependency-propertiesdependencyobject

Customizing The DependencyObject Inheritance Tree


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?


Solution

  • 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.