public class MethodArgument
        : Freezable // Enable ElementName and DataContext bindings

Normally, ElementName and DataContext bindings are resolved based on the target dependency object’s position within the element tree (or the namescope to which the target dependency object belongs).  But in this case, the target dependency object is not actually in the tree.  Instead, it is just a property value on another object.  That other object may or may not be in the tree.

The reason the Freezable trick works is because a Freezable object has its own notion of “inheritance context”.  When the property engine sets the effective value of a dependency property, it looks at that new value to determine whether it is a dependency object that would like to be part of a special inheritance tree.  A Freezable is one such object that always wants to be in the inheritance tree when not frozen.  As such, when the Command property on Button is set to a Freezable in Mike’s example (below), the framework adds the Button itself as the inheritance context of the Freezable.

    <Button Content="Rename"> 
      <Button.Command>
        <mc:MethodCommand MethodName="Rename">
          <mc:MethodArgument Value="{Binding Text, ElementName=_renameTextBox}" />
        </mc:MethodCommand> 
      </Button.Command>
    </Button>

The MethodCommand object above will now have the Button as its inheritance context. As such, even though MethodCommand is not a FrameworkElement with a tree-inherited DataContext property, it still effectively inherits the data context of the Button.  A binding on any property of the MethodCommand object will use its inheritance context to arrive at an implicit binding source (which will be the DataContext of the Button in this case).

The same construct is used to pass the inheritance context from a MethodCommand to its MethodArgument objects, so that their bound properties, too, can be resolved.

(Note that a Freezable can also have more than one inheritance context, but I’ll leave the discussion of how multiple inheritance contexts are handled for a future post.)

In addition to the above scenario (where a freezable is set as a dependency property value on a dependency object), it is this enhanced notion of an inheritance tree and inheritance context that allows bindings on brushes, animations, and other freezable objects to work when those objects are placed within a resource dictionary.

Mike’s approach is definitely a cool trick and I’ve used it myself on occasion.  Of course, there are scenarios where inheriting from Freezable is not really an option.  In such situations, the hack I find most useful for enabling bindings on non-freezable objects is to artificially add such objects to the logical tree.  But I would love to see Microsoft publicly expose the ability to control an object’s inheritance context so that all these hacks could just go away.  (Hint, hint! ;))

This entry was posted on Thursday, May 22nd, 2008 at 8:04 pm and is filed under Bindings, Freezables, WPF. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.