If you’re like me, you sometimes want to prove out a concept in XAML before implementing the “real” solution.  For example, you may want to create a new control which is very similar to an existing control, but lacking a property or two.  Rather than derive the control from a base class and add the new properties, it might be nice to simply re-template the existing control and pretend that it has the necessary properties.

Luckily, WPF makes this fairly easy through its support for attached properties.  It’s very likely that the framework has already defined a couple of properties of the very type you are needing.  If you cannot find an exact match, you can usually find something close enough.

Anyone who follows my posts in the WPF forum knows that I’m a big fan of “borrowing” attached properties from the framework.  This is especially useful in the forum because it allows me to provide a XamlPad-ready solution to demonstrate a concept.  Here are a couple of examples:

• MultiDataTrigger in style problem
• Styles and databind

Over the years, I have assembled a catalog that includes most of the framework-defined, public attached DPs (yes, I’ve spent far too many hours in reflector and writing code that greps the framework :P), as well as all of the relevant information about those DPs.  For anyone who is similarly inclined to “borrow” from the framework, here is my spreadsheet of attached DPs.

A few words of caution… 

• You should always know what the owner class does with any property you borrow.
• You should pay attention to default values and inheritance.  Sometimes you need a bool property with a default value of true… other times you may want a default value of false.  Sometimes you need a property that inherits… other times you explicitly don’t want inheritance.  (Borrowing a property like TextElement.FontSize could really screw up things lower in the tree.)
• The owner class may sometimes define a PropertyChangedCallback that will interfere with your ability to use the property as you wish.  Always know what the owner class does with the property.
• The owner class may provide a validation routine for the property that prevents you from entering the value you want to specify.  Again, always know what the owner class does with the property.
• The property may be registered in a manner that makes it costly perf-wise, such as FixedPage.Bottom which invalidates the parent’s arrange anytime the property changes on an object.  Sometimes you may explicitly want this behavior… other times it will just unnecessarily cause layout passes.  Again, always know what the owner class does with the property.
• If you use a property in a scenario where the framework itself is trying to use the property (such as TextSearch.TextPath on an ItemsControl), you are liable to find yourself in contention with the framework.

Okay, I’m sure I could go on, but you get the general idea.

The nice thing about this spreadsheet is that it has all of the information you might want to know about the properties, including the following:

• Defining Class / Owner Type
• Property Name
• Type
• Metadata Type
• Default Value
• Owner Handles Changes (the owner registered a PropertyChangedCallback)
• Coerced (the owner coerces the value)
• Validation (the owner validates the value)
• Inherits
• Metadata Options

It also contains a second worksheet with a pivot table that can be used to easily filter the properties down to exactly those that meet your needs.  And remember, if you can’t find a property that matches the exact type you’re looking for, you can usually just use a DP of type string because there are type converters for most objects that are capable of translating to/from string values.  And there are a few properties of type ‘object’ that can serve as uber-utility DPs.

Let the borrowing begin!
Dr. WPF