Silverlight Styles and Templates

Analogy categoryAnalogies

Styles: Centralizing Property Values

A Style in Silverlight is a keyed resource containing a collection of Setter objects, each assigning a value to a dependency property on a specific TargetType. Applying a Style to a control (either explicitly via the Style property or implicitly by omitting x:Key so it targets every control of that TargetType in scope) lets you set FontSize, Background, Padding, and other properties once instead of repeating them on every instance. Styles can also derive from one another using BasedOn, letting a specialized style inherit and override a subset of setters from a base style.

🏏

Cricket analogy: A team's official kit style, cap color, jersey number placement, sponsor logo position, is defined once and applied to every player, just as a Silverlight Style's Setters apply the same property values across every Button in scope without repeating them per player or per control.

ControlTemplate: Replacing Visual Structure

While a Style only sets property values, a ControlTemplate completely replaces the visual tree that a control renders, letting you redesign, for example, a Button as a rounded gradient pill with a glow effect while retaining its Click behavior, keyboard focus handling, and command logic untouched. Inside a ControlTemplate, TemplateBindings connect template elements back to the control's own properties (such as binding a Border's Background to the templated Button's Background), and the special ContentPresenter element marks where a ContentControl's Content should render within the new visual structure.

🏏

Cricket analogy: Restyling a Button with a ControlTemplate is like a franchise redesigning its team logo and kit entirely for a new season while the underlying player roster, batting order, and match rules stay exactly the same.

VisualStateManager and States

Modern Silverlight ControlTemplates (from Silverlight 3 onward) declare their interactive states through VisualStateManager, grouping related states such as CommonStates (Normal, MouseOver, Pressed, Disabled) inside VisualStateGroups and defining, per state, a Storyboard that animates template elements to reflect that state; the control's own code (for example, Button's internal logic) calls VisualStateManager.GoToState to transition between states, and template authors only need to supply the Storyboards, not write any state-transition logic themselves.

🏏

Cricket analogy: VisualStateManager grouping CommonStates like Normal, MouseOver, and Pressed is like a scoreboard operator having pre-built display templates for Batting, Fielding, and Rain Delay states, and simply switching the active template when the umpire signals a change rather than redesigning the board each time.

xml

<Style x:Key="RoundedButtonStyle" TargetType="Button">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="Button">
                <Grid>
                    <vsm:VisualStateManager.VisualStateGroups>
                        <vsm:VisualStateGroup x:Name="CommonStates">
                            <vsm:VisualState x:Name="Normal" />
                            <vsm:VisualState x:Name="MouseOver">
                                <Storyboard>
                                    <ColorAnimation Storyboard.TargetName="Background"
                                        Storyboard.TargetProperty="(Rectangle.Fill).(SolidColorBrush.Color)"
                                        To="#FF3388CC" Duration="0:0:0.15" />
                                </Storyboard>
                            </vsm:VisualState>
                            <vsm:VisualState x:Name="Pressed" />
                        </vsm:VisualStateGroup>
                    </vsm:VisualStateManager.VisualStateGroups>

                    <Rectangle x:Name="Background" RadiusX="8" RadiusY="8"
                               Fill="{TemplateBinding Background}" />
                    <ContentPresenter Content="{TemplateBinding Content}"
                                       HorizontalAlignment="Center"
                                       VerticalAlignment="Center" />
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Because Style Setters and ControlTemplate can both be packaged into a Style keyed by TargetType, a full "skin" for a control, colors, fonts, and structure, can be swapped at runtime by simply assigning a different Style resource to the Style property.

A ControlTemplate that omits ContentPresenter for a ContentControl (or the correct TemplateBinding wiring) will silently fail to display the control's Content, even though no error is thrown — always verify the templated control actually shows bound content after a custom template is applied.

A Style holds Setter objects that assign dependency-property values for a given TargetType.
Implicit styles (no x:Key) apply automatically to every control of that TargetType in scope; explicit styles require the Style property to be set.
BasedOn lets one Style inherit and selectively override another Style's Setters.
ControlTemplate replaces a control's entire visual tree while preserving its underlying behavior and logic.
TemplateBinding connects a template element's property to the templated control's own property value.
ContentPresenter marks where a ContentControl's Content renders inside a custom ControlTemplate.
VisualStateManager groups named states (like CommonStates: Normal/MouseOver/Pressed) with Storyboards the control triggers via GoToState.