Setting a style on the element level simply means that only this specific element will be affected by that style. To style an element on the element level, we simply add the desired property setting, such as FontSize, directly within the element declaration line. Let's change the font size of the first TextBox control. Locate the following line of code in your MainPage.xaml file:

<TextBox Text="{Binding FirstName, Mode=TwoWay}"/>

Change the preceding line of code as follows:

<TextBox Text="{Binding FirstName, Mode=TwoWay}" FontSize="22"/>

Build and run your application, and you will notice the font size of the first TextBox control is much bigger than the rest of the TextBox controls. Let's change the color of the text inside the textbox as well. Add the following line of code right after the FontSize property in your TextBox declaration line:

Foreground="BlueViolet"

Build and run your application, and you'll see that the text now has a blue-violet color.

Lastly, let's make the text in the TextBox control bold. Add the following line of code right after the Foreground property in your TextBox declaration line:

FontWeight="Bold"

Build and run your application. The end result should look similar to the following screenshot:

While this type of styling is fine for setting the design properties on a single element, it gets quite messy when multiple elements of the same kind need to have the same style properties. Think about our form for example, if we wanted to make all the TextBox elements have a red font, we would need to copy the style declaration of the foreground color over and over again to every one of the TextBox controls in the form. And what if you suddenly need to change the font color to green? You'll then have to fix the same font style declaration on each and every one of the TextBox controls. That might be ok if you have two or three controls to design, but what if you have fourteen or a hundred? To tackle this problem you can use page-level styling and that is what we are going to talk about next.

In its core, the page-level styling is the same as the element-level styling, but instead of being applied on a single element, the style will be applied on all the elements of the same type in that specific page. A page-level style is defined under the top parent element (in our case, UserControl as we are editing MainPage.xaml) by using the attached property—Resources. An empty page-level styling will look as follows:

<UserControl.Resources>
</UserControl.Resources>

Inside the Resources elements, we define any style we wish to share among the different elements of the page.

There are three types of page-level styling—explicit, implicit, and BasedOn. Up until Silverlight 4, explicit styling was the only way to set a style in Silverlight but ever since Silverlight 4 introduced the concept of implicit styles, it became quite a popular addition. We will start our journey of page-level styling with explicit styles, move on to implicit styles, and finish up with the BasedOn styling mechanism.

Explicit styling

An explicit style is a style that has its TargetType property set. To apply an explicit style to an element, you must define the style name as a static resource in the element's Style property.

Once you declare a style, you can define the content of the style (the styles you are applying) using the Setter elements. The Setter element contains two properties as follows:

• Property: This gives the name of the property you wish to style (for example, FontSize)
• Value: This is the styling value (for FontSize, it can be 22, 24, or any other font size you wish)

Let's take the TextBox style, which we defined in the previous example and transform it into an explicit style at the page level. The code for that style will look as follows:

<UserControl.Resources>
<Style x:Key="TextBoxStyle" TargetType="TextBox">
<Setter Property="FontSize" Value="22"/>
<Setter Property="Foreground" Value="Violet"/>
<Setter Property="FontWeight" Value="Bold"/>
</Style>
</UserControl.Resources>

In the preceding example, we have defined a style called TextBoxStyle, which will target elements of the TextBox type and format them to have a font size of 22, a foreground color of violet, and a bold weight.

Copy and paste the preceding code snippet to your MainPage.xaml page just under the UserControl element (above the LayoutRoot Grid element). If you compile and run your application now, you will see that no textbox has changed its style according to what we wrote. The reason for that is explicit styles need to be explicitly set on elements. For every TextBox control on your page, add the following line of code before the closing bracket:

Style="{StaticResource TextBoxStyle}"

By binding the Style property to the name of style we have just created, we explicitly set the style of the element to the style we defined.

Note

It's important to remember to only bind a style to an element of the same type of the style's TargetType property. Binding a style to an element of the wrong type will result in a compilation error.

Build and run your application, and you should see that all the textboxes are now styled based on our definition:

The big advantage of using page-level explicit styling is that you can now edit the style in one central location, and all the elements that inherit it will change accordingly. Let's make the font size of our textboxes smaller. In your style definition, change the value of the FontSize setter to 15. The complete style should look as follows:

<UserControl.Resources>
<Style x:Key="TextBoxStyle" TargetType="TextBox">
<Setter Property="FontSize" Value="15"/>
<Setter Property="Foreground" Value="Violet"/>
<Setter Property="FontWeight" Value="Bold"/>
</Style>
</UserControl.Resources>

Build and run your application and you'll notice the font size of the TextBox elements is smaller now.

Another advantage of using explicit styling comes into play when you want to have different styles for the same type of element. Nothing stops you from defining another TextBox style on your page and using it with the selected TextBox elements. Let's add another style for the TextBox element on our page. Copy and paste the following code just below the closing element of our previous style:

<Style x:Key="TextBoxStyleRed" TargetType="TextBox">
<Setter Property="FontSize" Value="15"/>
<Setter Property="Foreground" Value="Red"/>
</Style>

Next, find the TextBox elements of Phone Number and Employee ID, and change the binding of the Style property from TextBoxStyle to TextBoxStyleRed. Build and run your application, and you should get the result, as shown in the following screenshot:

Explicit styling is great when you wish to have different styles for the same type of element within a selected page. Unlike element-level styling, you have one central place to edit the styles of all the elements, your code looks much cleaner, and you can define different styles for the same type of element within the same page.

Implicit styling

We've just seen how explicit styling works and what its advantages are, but think about what happens when you are dealing with a large-scale application that has hundreds of controls. Going through each one and setting its style property can be tiresome and very error-friendly. This is where implicit styling kicks in. Implicit styles were first introduced in Silverlight 4, and they are very similar to their explicit counterpart with one exception—they don't have a key. If you look back at the Explicit styling section, you'll see that each explicit style we defined had the key property. That property was mandatory, and the elements that wanted to use that style had to specify it. With implicit styling you define the style exactly the same, but as you omit the key property, the TargetType property becomes the key, and the style implicitly affects all the elements of that type with one exception—if the element we target already has a defined style, the implicit style won't affect it.

Let's revisit the explicit style's example and make it implicit. Go over the code and remove all the Style attributes from the TextBox elements. Next, remove the x:Key property from the first TextBox style on your page. Build and run your application, and you should get a result similar to the following screenshot:

By removing the key property of a style, we've changed its nature from needed to be explicitly called by an element to implicitly affect all elements of the style's type.

BasedOn styling

Implicit styling is useful for sure, but what happens when you define more than one implicit style for the same element in a page? Well, you get a runtime error, that's what.

If you want to emulate CSS, which can cascade styles, you can use the BasedOn system for your styling. Using BasedOn, you can create a base style for your page (for example, all the textboxes will have the font size of 15) and then create an addition style based on it.

BasedOn styling is not unique to implicit or explicit styling and, in fact, it uses a combination of both. To understand BasedOn styling better, let's see an example of how to use it. Delete all the styles inside your UserControl.Resources element and then add the following code:

<Style x:Key="BaseTextBoxStyle" TargetType="TextBox">
<Setter Property="FontSize" Value="15"/>
</Style>

There is nothing you haven't seen before in the preceding code. It's an explicit style named"BaseTextBoxStyle" aimed at the TextBox element, which sets the FontSize property to 15. But, this is only the first half of our BasedOn style. Now, we can create a style that will be based on our base style. Add the following code below the closing element of the previous style:

<Style TargetType="TextBox" BasedOn="{StaticResource BaseTextBoxStyle}">
<Setter Property="Foreground" Value="Red"/>
</Style>

This looks like any other implicit style we defined in the previous part except for one major difference—it has a property called BasedOn, which is bound to the base style we defined just a minute ago. Build and run your application, and you should get something similar to the following screenshot:

We have just created an implicit style that is based on a base style. BasedOn styles are great time savers and let you create a clearer, better-understood code when you have styles that are very similar in nature but differ in their properties.

Up until now, we have dealt with element-level styling and page-level styling. The last level of styling that Silverlight offers us is the global level. Styles in the global level are styles that can be used throughout your application and not just on a single page. Explicit, implicit, and BasedOn styles do not have to be defined at the page level. These kinds of styles can happily be set at the global level, too. With global-level styling, we are basically talking about defining styles in the App.xaml file. If you open up your App.xaml file right now, you should see only the following lines of code:

<Application.Resources>
</Application.Resources>

If this looks familiar to you, then it is no coincidence. If you look back at the page-level styling, you will see that all the styles were written under the UserControl.Resources node. Application.Resources defines resources that are to be used at the application (global) level and, thus, have to be written under a global scope. Let's consider the following scenario:

You are building an application that uses a wizard form where users can go from one page to another. If you define all the styles for that application on the element level, you would have a big mess on your hands. If you define all the styles on the page level, you would basically have duplication of code, because for each style you define on page one, you have to define another on page two. The solution here is global-level styling. You define the styles once at the global level and both pages (and others that you might add in the future) can use it. All your code is centralized and easily maintainable.

As styles on the global level are just like their sibling on the page level, you can take all the styles we wrote in the previous part and move them right into the App.xaml file. If you build and run your application once the change is done, you will see that the user interface is exactly the same.

Just like most things in life, styles have a clear order of hierarchy. Knowing about this hierarchy can help you when you wish to override certain styles or even modify a global style on a specific element. The style hierarchy in Silverlight strongly resembles the hierarchy of styles/CSS in HTML. First, you have the global styles; these styles are the weakest in the style hierarchy and can be overridden by both page-level styles and element-level styles. To demonstrate this hierarchy, open a new Silverlight application project in Visual Studio 2010, and add a Button control to MainPage.xaml. Once the button is in place, edit the App.xaml file, and add the following style between the opening and closing of the Application.Resources element:

<Style TargetType="Button">
<Setter Property="Background" Value="Green"/>
</Style>

If you run your application now, you'll see that the button has picked up the global style and its background is now greenish. Now, add the following code in your MainPage.xaml just under the top-level UserControl element:

<UserControl.Resources>
<Style TargetType="Button">
<Setter Property="Background" Value="Red"/>
</Style>
</UserControl.Resources>

Run your application now, and you'll notice that the button has a red flavor. What just happened is usually referred to as style overriding. Because the page-level styles are higher in the style hierarchy than the global level ones, they override the settings.

The same applies for element-level styling. Element-level styling is on top of the hierarchy and, thus, can override any other style. To recap, the main idea of this topic is that global-level styles are always at the bottom of the styles hierarchy, which means any style higher in the hierarchy will override them. Next in the styles hierarchy are page-level styles. Sitting at the top of the hierarchy are element-level styles. If you define a style to an element using its Style property directly, nothing will override it.