Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Binding Does Not a Dependency Property Make

0.00/5 (No votes)
3 Sep 2012 1  
This simple trick stops the binding gremlins on their tracks, as only a dependency property can be their target.

In WPF/Silverlight, we are all accustomed to writing things like Width="{Binding foo}" and Text="{Binding bar}". The little Binding gremlins then actually access foo or bar property of the current data context and put its value into Width or Text.

But last night, I ran into a nasty problem: what if I wanted to capture the binding itself, to apply it later in a different data context? I tried to create a dependency property of type Binding, but it did not work. When I wrote <MyClass MyBinding={Binding whatever}" /> in XAML, the little binding gremlins were there again and attempted to get the value of whatever from the current data context, failing miserably. There seemed to be no way to tell them not to do that and just return a Binding object.

But then, it hit me: WPF DataGrid columns have a property called Binding that does exactly what I needed: it grabs a binding from XAML and then applies it to the data items of the grid one by one. Careful examination of the DataGridBoundColumn class revealed that Binding is NOT a dependency property, it’s a regular CLR property.

This simple trick stops the binding gremlins on their tracks, as only a dependency property can be their target. Problem solved!

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here