Brian Lagunas » Get DependencyProperty by Name for WPF and Silverlight

Get DependencyProperty by Name for WPF and Silverlight

Have you ever needed to create bindings to elements without knowing, or having access to, their DependencyProperty until runtime?  Have you ever had the need to get the DependencyProperty of an element at runtime for any reason at all?  If so, then this code snippet may be of use to you.

public static DependencyProperty GetDependencyPropertyByName(DependencyObject dependencyObject, string dpName)
{
    return GetDependencyPropertyByName(dependencyObject.GetType(), dpName);
}

public static DependencyProperty GetDependencyPropertyByName(Type dependencyObjectType, string dpName)
{
    DependencyProperty dp = null;

    var fieldInfo = dependencyObjectType.GetField(dpName, BindingFlags.Public | BindingFlags.Static | BindingFlags.FlattenHierarchy);
    if (fieldInfo != null)
    {
        dp = fieldInfo.GetValue(null) as DependencyProperty;
    }

    return dp;
}

 

The usage is simple.  One method allows you to pass in the dependency object instance, plus the string representation of the DependencyProperty on the object.  The other method allows you to get a dependency object from a Type.  The most important thing to remember is the dpName parameter is the full name of the DependencyProperty as it is declared, not the property name you reference in code or XAML. 

Consider the following example:

var usingInstance = GetDependencyPropertyByName(_button, "ContentProperty");

var usingType = GetDependencyPropertyByName(typeof(Button), "ContentProperty");

 

As you can see, the dpName parameter is the actual DependencyProperty name (ContentProperty) and not the property name (Content).  Now that you have the DepedencyProperty, you can get all kinds of meta data about the property, and even creating dynamic data bindings.  I hope this is helpful.

Tags / ,

Comments  (3 )

John Doe
on Wed, Jan 30 2013 2:02 AM

These are not really valid scenarios. One does not need to have the DependencyProperty instance to create a binding as all what's needed is the name (which is give in the example above). And even if you do need an instance of the DependencyProperty, there is  probably something wrong with the design. Moreover, this will only work if the name of the DP field matches the first argument of the Register method ("name"). I think the more valid scenario here is how to get the attached dependency properties of an object and their values.

Brian Lagunas
on Wed, Jan 30 2013 3:56 AM

Hello Alex Fidanov a.k.a. "John Doe", I am curious on what scenario you were thinking of that doesn't require you to know the DependencyProperty in order to create a binding between two objects.  Both FrameworkElement.SetBinding and BindingOperations.SetBinding require a DependencyProperty as a parameter.  If you were thinking that using SetBinding(TextBox.TextProperty, ...) was just using a name then you are mistaken.  That is actually using the static instance of the TextProperty DependencyProperty.  The same instance the above code snippet will give you.

Which leads me to my next question, of why would you consider something wrong with a design that requires the ability to dynamically create bindings between two objects?  How else would you create a mechanism for providing a two way system for updating values between the target and the source of the value dynamically at runtime?

Also, you are incorrect in your statement about how this will not work unless the DP field matches the "Name" parameter of the Register method.  This code gets the static field of the DependencyProperty itself.  The DP can be named anything you want and has nothing to do with the parameters provided in the DependencyObject.Register method.  That's why it is important that you provide the DP name.  My DP can be named MySuperCoolDpProperty, and the "Name" in the DP.Register method could be "Cheese", and this would work correctly.

Leonid Osmolovski
on Tue, May 21 2013 12:32 PM

Hi, Brian

This is exactly what i need. I've wasted valuable time in looking for such mechanism and stumbled on explanation that GlobalIndex and GetHashCode of DependencyProperty class are for internal use only and do not provide access to internal List where registered dependency properties "are stored" .

I hope your solution will work and i will check it immediately.

BTW, could you hint something about the hidden  features that suddenly make access to registered dependency property through a field of the dependency object - how does this relate to internal list of all dependency properties?

Best regards

Add a Comment

Please Login or Register to add a comment.