This creates a new, nameless, instance of the DataClass class and then sets its MyProperty2 to 35. Notice that Attribute setting can be used for MyProperty2 because it is a supported value property however there would be no problem if MyProperty was another reference property – the nesting might get a little deep however!

Implementing a type converter

As an alternative to using nested property syntax to set reference properties, we can opt to handle the conversion from the initializer string to the object properties ourselves.

Surprisingly this isn’t difficult.

For example, suppose we want to allow MyProperty2 to be set by a string. All we have to do is tag the type that the type converter will apply to with:

The rest of the class is unaltered. Now we have to implement the MyDataClassTypeConverter and to do this we need to add:

using System.ComponentModel;

The type converter class has to inherit from TypeConverter and it first implements CanConvertFrom which simply returns true or false depending on whether or not the type converter can do the requested conversion:

Notice that it creates a new instance of the class that it performs type conversion for and then processes the string to initialise the properties of the MyDataClass instance. Notice also that the Type converter creates and then initialises the object to be stored in the property using the information supplied by the initialisation string.

Clearly a real example would be more complex and would parse the string to extract multiple items of initialisation information.

With the type converter in place we can create an instance of MyClass using:

You can similarly write code that manipulates any object or property initialised by XAML.

Where next?

It is clear that XAML is a very general and extensible object instantiation language. If you follow the example in this article I can promise you lots of difficulties caused by synchronisation – the project organisation used in this article was adopted to make the example simple and thus falls over in the real world.

The problem is that XAML doesn’t expect the assemblies that contain the classes it is instantiating to change during development. This is easily cured by splitting out the class definitions into another assembly.

In the final analysis you have to ask yourself if XAML is worth it. Is it really so much better to instantiate objects declarative with all of the type conversion and namespace problems this brings about?

For some situations the declarative approach to object creation makes sense - UIs for example. In other case you need to think carefully and if you decide to create a declarative system using XAML you will almost certainly have to create a custom editor for the objects.

Knowing how XAML works, for WPF or WinRT apps is well worth the effort however.

Routed events were new in .NET 3.5 but there is still plenty to discover about using them. We look at bubbling and tunneling and how to create your own routed even and how WPF changes the underlying m [ ... ]

For a class to be instantiated by XAML it has to have a parameter-less constructor. This means that properties that might be essential to creating the instance can be initialized in any order and this [ ... ]