To find a resource, Silverlight recursively searches up the element tree terminating at the <Application.Resources> section in App.xaml file.

As an example, suppose I re-use a custom brush on multiple elements on my page. I put it in the <UserControl.Resources> section where it can be accessed by all elements on my page. It is defined as:

    <UserControl.Resources>
        <LinearGradientBrush x:Key="CustomBrush">
            <GradientStop Offset="0.00" Color="Yellow" />
            <GradientStop Offset="1.00" Color="Orange" />
        </LinearGradientBrush>
    </UserControl.Resources>

Using a Resource in XAML:

Now that my CustomBrush has been defined, it can be re-used in XAML. A given element needs a way to refer to this resource in order to reuse it. This is accomplished by using a markup extension. Markup extensions are a specialized syntax to set a property in a non-standard way, and are recognized by curly braces. For example, let’s say the Grid element needs to use the CustomBrush defined above:

	<Grid x:Name="outerGrid" Background="{StaticResource BackgroundBrush}"

In this example, we use a markup extension named StaticResource. Here’s (MSDN) some more information about static and dynamic resources

Using a Resource in Code:

In order to use CustomBrush in my code (e.g. C#), I can access the Resources property as a dictionary by using the key to index and retrieve the specific resource.

            Grid outerGrid = new Grid();
            LinearGradientBrush customBrush = 
                (LinearGradientBrush) this.Resources["CustomBrush"];
            outerGrid.Background = customBrush;

I can even update my resource in code. If I wanted to change the color gradient of my CustomBrush, I would do so as follows:

            LinearGradientBrush customBrush = 
                (LinearGradientBrush) this.Resources["CustomBrush"];
            customBrush.GradientStops[0].Color = Colors.Brown;
            customBrush.GradientStops[1].Color = Colors.Red;

The really nifty bit is that every element that uses this customBrush will automatically update to use the new colors.

Silverlight does not support dynamic resources (but WPF does), and as a result it is not possible to update the resource reference with a new object. For example, the following code is not allowed in Silverlight:

            this.Resources["CustomBrush"] = new LinearGradientBrush();

Most commonly, attached properties are used in layout containers. Every control in XAML has its own set of internal properties. However, when this control is placed inside a container, it acquires additional features depending on the type of the container. For example, the Grid.Row property is created as an attached property because any control inside a Grid needs to specify the grid cell where it is positioned. For example:

<Grid x:Name="OuterGrid">
	<TextBox x:Name="innerBox" Grid.Row="1"/>
</Grid>

Since the TextBox is nested inside the Grid, it gains the Row property which "attaches" to the TextBox instance. In essence, attached properties allow different child elements to specify values for a property defined in a parent element. Attached properties always use a two-part name of the form: AttachedPropertyProvider.PropertyName (OR simply DefiningType.PropertyName)

Defining a Custom Attached Property:

Creating an attached property is similar to how we create a custom dependency property with a few subtle differences. Since I seem to love widgets so much, I will continue to use a custom WidgetControl as an example. In one of my previous posts we saw how to create a custom dependency property for WidgetControl. In this post, we will see how to create the WidgetStateProperty as an attached property.

1. The first step is to define a static readonly DependencyProperty object that represents the property, and register this attached property with Silverlight. This is done via the Dependency.RegisterAttached() method.

        public static readonly DependencyProperty WidgetStateProperty =
            DependencyProperty.RegisterAttached(
                "WidgetState",
                typeof(Boolean),
                typeof(WidgetControl),
                new PropertyMetadata(false));

Notice that when we were creating custom dependency properties, we used the DependencyProperty.Register() method. The parameters for both these methods are exactly the same: the property name (WidgetState in this example), the data type used by the property (bool), the type that owns this property (WidgetControl), and a PropertyMetadata object that provides additional information, such as default values.

2. Our attached property provider must also provide static GetXXX() and SetXXX() methods, where XXX is the name of our property (WidgetState).

        public static void SetWidgetState(UIElement element, Boolean value)
        {
            element.SetValue(WidgetControl.WidgetStateProperty, value);
        }

        public static Boolean GetWidgetState(UIElement element)
        {
            return (Boolean)element.GetValue(WidgetControl.WidgetStateProperty);
        }

We now have a fully functioning attached property which can be set using the DefiningType.PropertyName syntax. The complete code for this WidgetControl is shown below:

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 Attached
{
    public partial class WidgetControl : UserControl
    {
        public WidgetControl()
        {
            InitializeComponent();
        }

        public static readonly DependencyProperty WidgetStateProperty =
            DependencyProperty.RegisterAttached(
                "WidgetState",
                typeof(Boolean),
                typeof(WidgetControl),
                new PropertyMetadata(false));


        public static void SetWidgetState(UIElement element, Boolean value)
        {
            element.SetValue(WidgetControl.WidgetStateProperty, value);
        }

        public static Boolean GetWidgetState(UIElement element)
        {
            return (Boolean)element.GetValue(WidgetControl.WidgetStateProperty);
        }
    }
}

Here’s a very simple example where we use WidgetControl and its WidgetState property. The code is in XAML:

<UserControl x:Class="Attached.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"
    xmlns:local="clr-namespace:Attached"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <local:WidgetControl>
            <TextBox x:Name="txtBox" local:WidgetControl.WidgetState="true">
            </TextBox>
        </local:WidgetControl>
    </Grid>
</UserControl>

Finally, a couple of good resources that talk more about dependecy and attached properties are here [msdn.microsoft.comhere [www.silverlightshow.net]

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)

(Note: My aim is to show the steps for adding a new control, so I will not go into the specifics of the control itself)

I am going to start by creating a new project (type: Silverlight Application) in Visual Studio. Let’s call it Widget. To add a new Custom control, right click on the project in Solution Explorer, and go to Add->New Item, as shown in the figure below:

We get to a selection dialog which lists the various items that can be added. Let’s select “Silverlight User Control”, and change the name of the XAML file to WidgetControl.xaml

For this example, my new control is a pretty basic control as it simply contains a TextBox. Open the WidgetControl.xaml file, and add the TextBox element. Once done, the WidgetControl.xaml.cs file looks like:

<UserControl x:Class="Widget.WidgetControl"
    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">
        <TextBox x:Name="txtBox" Text="Widget Box"></TextBox>
    </Grid>
</UserControl>

We can add new properties to our WidgetControl, and to illustrate this let’s add a new property called InternalText that is used to manipulate the text for the txtBox. Right click on the WidgetControl.xaml.cs file, and click on “View class Designer”.

When the class designer opens up right click on the WidgetControl class, click Add->Property.

Add the new String property called InternalText. Once the property has been added, the WidgetControl.xaml.cs file will be updated automatically to include the new property. The file looks as follows:

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 Widget
{
    public partial class WidgetControl : UserControl
    {
        public WidgetControl()
        {
            InitializeComponent();
        }

        public String InternalText
        {
            get
            {
                throw new System.NotImplementedException();
            }
            set
            {
            }
        }
    }
}

Since our new property simply wraps around the Text property of the TextBox, so let’s go ahead and implement our InternalText property:

        public String InternalText
        {
            get
            {
                return txtBox.Text;
            }
            set
            {
                txtBox.Text = value;
            }
        }

Using a Custom Control:

Once we’ve created a custom control, using it is pretty straightforward. All we need is to declare our xml namespace, and start using the control. Continuing my example, I’ve added my custom WidgetControl to MainPage.xaml file. The code to make this happen is on lines 6 & 11 below:

<UserControl x:Class="Widget.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"
    xmlns:wts="clr-namespace:Widget"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <wts:WidgetControl x:Name="widgetCtrl" InternalText="Let's Text"/>
    </Grid>
</UserControl>

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;