Charles Petzold

Content Properties

February 7, 2006
New York City

Consider the following simple Style definition:

Style has two similar properties named Setters and Triggers. Setters is basically a collection of Setter objects, and Triggers is basically a collection of Trigger objects. Yet, in the XAML these two collections are treated very differently. The Setter elements are simple children of Style. Yet the Trigger elements must be enclosed in the property element Style.Triggers. Within each Trigger definition, the Setter elements are also simple child elements.

Why is the Setters collection treated differently from the Triggers collection? If you check the documentation of the Style class, you won't get a hint. The answer is that the Style class definition is marked with a ContentProperty attribute, which looks something like this:

The Trigger class has an identical ContentProperty attribute. This attribute indicates to the XAML parser that elements that are children of Style in the markup are to be treated as members of the Setters property collection.

You would think that these content properties would be well documented, but they are not. I have been foced to write a program named DumpContentPropertyAttributes.csx (and rename to .cs) (with the DumpContentPropertyAttributes.csproj project file) to list them. (Good grief! It's a console app!)

Many of these will be obvious. Often the content property is named Children or Child or Content. But it's nice to see a complete list.

I was first alerted to the existence of the ContentProperty attribute in Chuck Jazdzewski's XAML Tours. Tours are nice but documentation is even better.

Someday XAML will be documented, and we will no longer be forced to stumble around in confusion.