Reviewing the Silverlight Control Programming Model
Over the course of many years, developers have been conditioned to see controls as fairly fixed and predictable
entities. For example, buttons have textual content and may on occasion have an embedded image.
When a project demanded that a ‘standard’ widget (such as a Button) needed to be customized such as a Button
control rendered as a circular image, developers were often forced to build a customized control through code.
Silverlight (and WPF) radically changes the way developers look at controls. Not only do developers have the
option to express a control’s look and feel through markup, but many Silverlight controls have been designed to
contain any sort of content. The UserControl class provides the Content property for setting content for the
Silverlight control itself. Any descendant of ContentControl can participate in this new model.
Recall from Chapter 1 that the Silverlight content model demands that content can only be represented as a single
item. When you need to assign complex content, you will wrap each UI element into one of the panel types. The
panel will contain all the nested UI elements. The panel then becomes the ‘single piece of context’.
You’ll examine the Silverlight panel types in detail later in this chapter.
Recall the following customized Button class from Chapter 1. Notice the button’s content is a <StackPanel>,
which defines two sub-elements.
<Button Height = "150" Width = "120" x:Name = "btnMyButton">
<!-- This button has a StackPanel as IMPLICIT content. -->
<StackPanel>
<Ellipse Fill = "Orange" Height = "75" Width = "75"/>
<TextBlock Text = "OK!" FontSize = "20" HorizontalAlignment = "Center" />
</StackPanel>
</Button>
Recall that the first sub-element of a ContentControl derived type will implicitly set the content. If the content can
be captured as a string literal, you can set the Content property within the opening element of the control’s
definition.
You could also make use of property element syntax to explicitly define content. For example, the previous Button
could be authored as so:
<Button Height = "150" Width = "120" x:Name = "btnMyButton">
<!-- This button has a StackPanel as EXPLICIT content. -->
<Button.Content>
<StackPanel>
<Ellipse Fill = "Orange" Height = "75" Width = "75"/>
<TextBlock Text = "OK!" FontSize = "20" HorizontalAlignment = "Center" />
</StackPanel>
</Button.Content>
</Button>
Recall that any control defined in XAML with a x:Name attribute can then be accessed in a related code file. For
example, you could change properties on the previous button as follows, given that you assigned a Name value of
btnMyButton.
// C# code (VB code would be similar).
public partial class Page : UserControl
{
public Page()
{
InitializeComponent();
btnMyButton.Height = 400;
}
}
This is possible because controls that are given a Name attribute in the XAML definition result in a member
variable in the autogenerated *.g.cs / *.g.vb file. For example, the previous XAML results in the following C# code
(VB code would be similar). Notice that the <StackPanel> types are not listed as member variables, as you have
not set a Name property to them.
// C# code (VB code would be similar).
public partial class Page : UserControl
{
...
// Member variables defined based on the XAML markup.
internal System.Windows.Controls.Button myBtn;
}
Over the course of many years, developers have been conditioned to see controls as fairly fixed and predictable
entities. For example, buttons have textual content and may on occasion have an embedded image.
When a project demanded that a ‘standard’ widget (such as a Button) needed to be customized such as a Button
control rendered as a circular image, developers were often forced to build a customized control through code.
Silverlight (and WPF) radically changes the way developers look at controls. Not only do developers have the
option to express a control’s look and feel through markup, but many Silverlight controls have been designed to
contain any sort of content. The UserControl class provides the Content property for setting content for the
Silverlight control itself. Any descendant of ContentControl can participate in this new model.
Recall from Chapter 1 that the Silverlight content model demands that content can only be represented as a single
item. When you need to assign complex content, you will wrap each UI element into one of the panel types. The
panel will contain all the nested UI elements. The panel then becomes the ‘single piece of context’.
You’ll examine the Silverlight panel types in detail later in this chapter.
Recall the following customized Button class from Chapter 1. Notice the button’s content is a <StackPanel>,
which defines two sub-elements.
<Button Height = "150" Width = "120" x:Name = "btnMyButton">
<!-- This button has a StackPanel as IMPLICIT content. -->
<StackPanel>
<Ellipse Fill = "Orange" Height = "75" Width = "75"/>
<TextBlock Text = "OK!" FontSize = "20" HorizontalAlignment = "Center" />
</StackPanel>
</Button>
Recall that the first sub-element of a ContentControl derived type will implicitly set the content. If the content can
be captured as a string literal, you can set the Content property within the opening element of the control’s
definition.
You could also make use of property element syntax to explicitly define content. For example, the previous Button
could be authored as so:
<Button Height = "150" Width = "120" x:Name = "btnMyButton">
<!-- This button has a StackPanel as EXPLICIT content. -->
<Button.Content>
<StackPanel>
<Ellipse Fill = "Orange" Height = "75" Width = "75"/>
<TextBlock Text = "OK!" FontSize = "20" HorizontalAlignment = "Center" />
</StackPanel>
</Button.Content>
</Button>
Recall that any control defined in XAML with a x:Name attribute can then be accessed in a related code file. For
example, you could change properties on the previous button as follows, given that you assigned a Name value of
btnMyButton.
// C# code (VB code would be similar).
public partial class Page : UserControl
{
public Page()
{
InitializeComponent();
btnMyButton.Height = 400;
}
}
This is possible because controls that are given a Name attribute in the XAML definition result in a member
variable in the autogenerated *.g.cs / *.g.vb file. For example, the previous XAML results in the following C# code
(VB code would be similar). Notice that the <StackPanel> types are not listed as member variables, as you have
not set a Name property to them.
// C# code (VB code would be similar).
public partial class Page : UserControl
{
...
// Member variables defined based on the XAML markup.
internal System.Windows.Controls.Button myBtn;
}
Silverlight Control Programming Model
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services