At a minimum, for a class to conform to the Silverlight implementation of TypeConverters it must be a subclass of the TypeConverter class and must contain the following two members for converting from strings for XAML processing:

1. The class must override the CanConvertFrom(…) method:

public virtual bool CanConvertFrom(
    ITypeDescriptorContext context,
    Type sourceType
)

It must return true when the sourceType parameter is String, and otherwise defer to the base implementation.

2. The class must provide an implementation of ConvertFrom(…) method:

public virtual Object ConvertFrom(
    ITypeDescriptorContext context,
    CultureInfo culture,
    Object value
)

To be usable as a TypeConverter implementation that supports XAML, this method must accept a string as the value parameter. If the string is valid, the returned object must support a cast to the type expected by the property. Otherwise it must return null.

The .NET specification for TypeConverters also contains two more key methods, which are ConvertTo and CanConvertTo. However, Silverlight 3 (as well as Silverlight 4 Beta) does not use ConvertTo and CanConvertTo, so you can skip these if your TypeConverter is for Silverlight’s XAML processing. It’s still a good idea to implement these two as a best practice for completing the wider interoperation functionality of the converter class.

Putting it all together: An Example:

Suppose I have a custom Silverlight control called WidgetControl, that has a property called WidgetHeight. If you need to see how to add custom controls to your project, please check out my post "Adding a Custom Silverlight Control". I use this control in my XAML file as follows:

<Custom:WidgetControl x:Name="widget" WidgetHeight="2 inches"/>

Somehow I need to handle the case where the unit of length is specified for the value of WidgetHeight property. This is done via a custom XAML TypeConverter called CustomLengthConverter, which is shown below:

    public class CustomLengthConverter : TypeConverter
    {
        public override bool CanConvertFrom(
            ITypeDescriptorContext context, Type sourceType)
        {
            if (sourceType == typeof(string))
            {
                return true;
            }
            return base.CanConvertFrom(context, sourceType);
        }


        public override object ConvertFrom(ITypeDescriptorContext
                context, CultureInfo culture, object value)
        {

            if (value == null)
            {
                return new Double();
            }
            if (value is string)
            {
                string s = (string)value;
                if (s.Length == 0)
                {
                    return new Double();
                }

                string[] arguments = s.Split(' ');
                if (arguments.Length != 2)
                {
                    throw new ArgumentException("Value must have the format <number length_unit>");
                }
                else
                {
                    return InternalParseInput(arguments[0]);
                }
            }

            return base.ConvertFrom(context, culture, value);
        }


        public Double InternalParseInput(String inputString)
        {
            Double doubleValue;

            try
            {
                doubleValue = Double.Parse(inputString);
            }
            catch(Exception){
                doubleValue = new Double();
            }

            return doubleValue;
        }
    }

Finally, in my WidgetControl class, I explicitly specify that the WidgetHeight property should use the CustomLengthConverter defined above:

    public partial class WidgetControl : UserControl
    {
	...

        [TypeConverter(typeof(CustomLengthConverter))]
        public Double WidgetHeight
        {
	   ...
        }
    }

So every time my XAML for WidgetControl’s WidgetHeight property is parsed, the parser uses the CustomLengthConverter to convert the property value from String to the appropriate .NET type (Double)

In the context of Silverlight, a TypeConverter is a class which knows how to convert between a String and a .NET type. For each attribute in XAML, the parser follows a two-step process to find the appropriate type converter:

1. The XAML parser checks the declaration of the property that corresponds to the XML attribute, and tries to see if the property contains a TypeConverter attribute. The TypeConverter attribute specifies the class that can perform the type conversion from String to the .NET type of the property. The parser then uses the TypeConverter class to convert the XML attribute into a .NET type.

2. If the property declaration does not contain a TypeConverter attribute, the XAML parser looks at the property’s Type, to see if it containts TypeConverter attribute declaration.

3. If neither the property declaration or type (class) declaration have an associated TypeConverter attribute, the XAML parser returns an error.

Let’s consider a couple of examples to better illustrate this. Suppose we have two .NET Types called a Widget and WidgetBox, which are defined as follows:

 
    public class Widget{
        public Brush Foreground
        {
        }
    }


    public class WidgetBox
    {
        [System.ComponentModel.TypeConverter(typeof(CustomLengthConverter)]
        public Double Height
        {
        }
    }

    public class CustomLengthConverter : System.ComponentModel.TypeConverter
    {
        ...
    }

Example-1:

Consider the following XML element in the XAML file.

	<WidgetBox Height="1in" />

1. When the XAML parser encounters this code, it checks the property declaration for Height. In this case, it finds a TypeConverter attribute for the Height property, which tells the parser to use the CustomLengthConverter class to convert the string "1in" to Double. So, this snippet of XAML code is equivalent to:

 
	WidgetBox wb = new WidgetBox();
	wb.Height = new CustomLengthConverter().ConvertFrom("1in");

Example-2:

Here’s another snippet of XAML code:

	<Widget Foreground="Blue" />

1. When XAML parser encounters this code, it first checks the property declaration for Foreground. There’s no TypeConverter associated with the Foreground property, so the parser moves to step-2.

2. Now the XAML parser checks the class declaration of the Foreground’s Type. In our example, the type of Foreground is Brush, and it turns out that the Brush class is decorated with the [TypeConverter(typeof(BrushConverter))] attribute declaration:

 
	[TypeConverter(typeof(BrushConverter))]
	public class Brush
	{
	...
	}

In this case, the parser uses the BrushConverter class to convert the string "Blue" into a Brush .NET type. So this snippet of XAML is equivalent to:

  
	Widget w = new Widget();
	w.Foreground = new BrushConverter().ConvertFrom("Blue");

For more information about TypeConverters, check out MSDN. There’s also a lot of great information at Rob Relyea’s blog post about TypeConverters

XAML document has the following properties:

- Every element in a XAML documents maps to an instance of a Silverlight (.NET) class, and its name exactly matches that of the class.
- The properties of each class can be set through attributes in the XAML file.
- Similar to any XML document, a XAML element can contain nested elements.

For example, when we create a new Silverlight application (called SampleApplication) in Visual Studio 2010 (beta), we get the following skeleton XAML document:

<UserControl x:Class="SampleApplication.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">

    </Grid>
</UserControl>

As I’ve mentioned before, XAML allows us to create user-interfaces. However, for the interface to be useful, it needs to connect to code (typically written in C#). To accomplish this, we need a way to connect the event handlers with the UI. Usually, every XAML file has a corresponding class with client-side C# code. This class is generated by the Class attribute in the XAML namespace. This attribute tells the Silverlight parser to create a new class with the specified name that derives from the class represented by the XML element. When the XAML code above is parsed, the parser creates a new class named SampleApplication.MainPage, which derives from the UserControl class. This class is in the file called MainPage.xaml.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SampleApplication
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
        }

    }
}

The class is partial , as it is split across two files. The code that we write goes into MainPage.xaml.cs. The rest of the class definition contains auto-generated code and goes into a file called MainPage.g.cs. In the solution, this file is located in obj\Debug folder. For the above XAML code, the contents of this auto-generated file are as follows:

using System;
using System.Windows;
using System.Windows.Automation;
using System.Windows.Automation.Peers;
using System.Windows.Automation.Provider;
using System.Windows.Controls;
using System.Windows.Controls.Primitives;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Interop;
using System.Windows.Markup;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Media.Imaging;
using System.Windows.Resources;
using System.Windows.Shapes;
using System.Windows.Threading;

namespace SampleApplication {

    public partial class MainPage : System.Windows.Controls.UserControl {

        internal System.Windows.Controls.Grid LayoutRoot;

        private bool _contentLoaded;

        /// <summary>
        /// InitializeComponent
        /// </summary>
        [System.Diagnostics.DebuggerNonUserCodeAttribute()]
        public void InitializeComponent() {
            if (_contentLoaded) {
                return;
            }
            _contentLoaded = true;
            System.Windows.Application.LoadComponent(this, new System.Uri("/SampleApplication;component/MainPage.xaml", System.UriKind.Relative));
            this.LayoutRoot = ((System.Windows.Controls.Grid)(this.FindName("LayoutRoot")));
        }
    }
}

Finally, a quick note about the Name attribute. If we want to access and manipulate Silverlight elements programmatically, XAML must include the Name attribute. This is useful if we want to change properties or attach and detach event handlers on the fly. In the above example, line-9 of the XAML file tells the XAML parser to add the following field to the autogenerated portion of the MainPage class

private System.Windows.Controls.Grid LayoutRoot;