Wahlin on .NET

Getting Started with Silverlight 2 Controls

Don't worry, ASP.NET developers: Siverlight 2 controls aren't so different from what you're used to, as Dan shows.

• By Dan Wahlin
• 06/16/2008

While Visual Studio 2008 doesn't currently allow Silverlight controls to be dragged and dropped onto the design surface, controls can be dragged from the toolbox and dropped into XAML files. For those looking for a more visual design experience, Microsoft's Expression Blend 2.5 allows Silverlight controls to be dragged from a toolbox directly onto the design surface. Developers accustomed to typing controls directly in code can do so directly in the XAML code editor, as well.

What Controls Are Available?
Silverlight 2 provides controls that perform basic tasks (such as collecting data) to more advanced tasks (such as playing media files and arranging items). Controls can be classified into four main categories: user input controls, layout controls, items controls and media controls.

Figure 1 shows the different Silverlight 2 controls in the toolbox (the controls shown were available as of Silverlight 2 beta 2).

User input controls include common controls found in many other frameworks -- such as TextBox, Button and CheckBox -- as well as some non-standard controls such as RepeatButton. Layout controls include controls such as Canvas, Grid and StackPanel, and items controls (used to show collections of items) include controls such as DataGrid and ListBox. Finally, media controls include MediaElement, Image and MultiScaleImage.

Using Silverlight Controls
Whether you type the controls directly into the code editor or drag them from the toolbox, you'll quickly learn that XAML isn't quite as forgiving as HTML and ASP.NET. XAML follows the rules defined in the XML specification, which means that tags have to be properly cased and closed and attributes must be quoted.

An example of defining a Silverlight TextBox control in a XAML file is shown below. Note that all of the tags defined in the XAML code have closing tags (or rely on shortcut closing tag syntax) and that all of the attribute values are quoted:

<UserControl x:Class="SilverlightApplication1.Page"
    xmlns="http://schemas.microsoft.com/client/2007" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBlock Text="Name" Margin="10" />
        <TextBox x:Name="txtName" Width="100" />
    </Grid>
</UserControl>

Looking through this XAML code, you'll notice that a Name attribute is used instead of the ID attribute found on ASP.NET controls. The x in front of the Name attribute represents an XML namespace prefix defined on the root UserControl element of the XAML file. Although you'll see x:Name used in many examples, Silverlight also allows the Name attribute (without the x namespace prefix) to be used.

Silverlight controls expose events just like ASP.NET server controls that can be handled by an event handler. For example, the Silverlight Button control exposes a Click event that can be handled using different languages such as C# or VB.NET. Here is an example of defining a Button control:

<Button x:Name="btnSubmit" Content="Go" 
    Click="btnSubmit_Click" />

The Button control's Click event is wired to an event handler named btnSubmit_Click by using the Click attribute -- similar to using the ASP.NET Button control's OnClick attribute in an ASPX file. When the event fires the following code is called:

private void btnSubmit_Click
    (object sender, RoutedEventArgs e)
{
    //Handle event 
}

You may wonder why Silverlight substitutes EventArgs for RoutedEventArgs. Silverlight relies on control trees behind the scenes to organize and manage parent and child controls. A root control acts as the start of the tree and child controls are nested under it. The root control's children can also have children of their own, which ultimately creates an object hierarchy or control tree.

The process of notifying a parent of an action that occurred on a child is referred to as a "routed event" because mouse or keyboard events triggered by a control are "routed" up the tree so a parent can be notified when an event occurs. Routed events are similar to event bubbling found in other languages.

I've only scratched the surface of Silverlight controls and introduced you to some of the fundamental concepts in this article. In future articles, I'll provide additional details about the controls and show how they can be used to build Silverlight applications.