The final part of the series is ready and it covers the following topics:

• Modifying Styles Runtime: the IsSealed Property – modifying the Setters of a Style can only be done if the IsSealed property is set to false and this property is set to true as soon as the style gets applied to an element in the visual tree.
• Cloning Styles – because sealed Styles can’t be modified, one needs to clone them to be able to manipulate them. I’m providing example code on how cloning of a Style can be done.
• Merging styles runtime – I’m showing two ways of merging existing styles programatically, both using the BasedOn property of Style as well as just copying Style setters.

You can read the detailed article and download source code for examples on my Visiblox blog – I hope you’ll find it useful.

The problem

I’ve come across this issue because I was trying to clone styles with the following extension method:

public static Style Clone(this Style style)
{
    if (style == null)
        return null;
    Style clonedStyle = new Style(style.TargetType);
    clonedStyle.BasedOn = style.BasedOn;
    foreach (Setter setterToCopy in style.Setters)
    {
        clonedStyle.Setters.Add(new Setter()
        {
            Property = setterToCopy.Property,
            Value = setterToCopy.Value
        });
    }
    return clonedStyle;
}

As you can see, this clone method is not doing anything complicated: it is simply iterating through the Setters of the Style and creating new Setter instances with the Property and Value of the original Setters – basically deep cloning the Style itself.

The issue in Silverlight 3

When I did clone a Style that had been created on the fly and had been assigned a the Style of an element, the values of Setters magically were set to null in Silverlight 3. The problem is visualized using the following simple code:

Style dynamicallyCreatedStyle = new Style(typeof(Rectangle));
dynamicallyCreatedStyle.Setters.Add(new Setter(Rectangle.StrokeThicknessProperty, 4));
dynamicallyCreatedStyle.Setters.Add(new Setter(Rectangle.StrokeProperty, new SolidColorBrush(Colors.Red)));
Rectangle1.Style = dynamicallyCreatedStyle.Clone(); // Works fine
Rectangle2.Style = dynamicallyCreatedStyle; // The Value of all Setters in dynamicallyCreatedStyle are set to null because of a Silverlight 3 bug
Rectangle3.Style = dynamicallyCreatedStyle.Clone(); // The Value of all Setters of dynamicallyCreatedStyle are null, thus Rectangle 3 won't be shown in Silverlight 3!

See the example in Silverlight 3 below. As you can notice, the third rectangle isn’t showing as the Style that it’s assigned to it (the clone of dynamicallyCreatedStyle) has all of it’s Setter Values set to null:

The issue in Windows Phone 7: exception being thrown

In Windows Phone 7 the same code still results in incorrect behaviour with an exception being thrown.

The Value of the Setter is not set to null, instead it’s value can’t be determined runtime, in the debugger. Cloning of this Style is still possible, however when assigning this cloned style to in this line:

Rectangle3.Style = dynamicallyCreatedStyle.Clone()

and ArgumentException is thrown with the error message The parameter is incorrect.

Silverlight 4: issue fixed

When compiling the very same code in Silverlight 4, the Values of the Setters of the dynamically created Style are no longer set to null. Here is the same example targeted for Silverlight 4:

Using Silverlight 4, the third rectangle is showing in the application. Kudos for the Silverlight team for fixing this (as far as I was aware) undocumented issue with Styles.

(Note: you can download the source of the example here: Silverlight 3 Styling Issue.zip)

Conclusion

It’s safe to say that due to this bug present in Silverlight 3 and Windows Phone 7, it’s definitely not recommended cloning Styles after they’ve been assigned to visual elements. If you’re forced to modify existing styles on visual elements, I’d suggest to constantly clone them before they’re applied to a visual element. Of course this is an expensive operation, so it’s definitely worth investigating if there are any other options available to avoid this happening in your application.

The third part of the series is ready and it covers the following topics:

• Style is a dependency property. Because of this, it supports the following features:
  • Data binding – it’s possible to bind a style to another (even though this is probably a very rare use case)
  • Property change notifications – it is possible to get notified when the Style property changes, a little workaround is needed though
  • ClearValue – when resetting the value of a Style, setting it to null may result in the element disappearing. It’s worth knowing what the difference between that and calling ClearValue are
• Declaring styles in code behind: creating styles programmatically is more complex that via XAML but at times this technique may be useful.
• Only dependency properties can be styled, styling CLR properties will result in either a compile time error or a runtime exception.
• Only classes descending from FrameworkElement have the Style property and thus can be styled.

You can read the detailed article on my Scott Logic blog – I hope you’ll find it useful.

The final part of the series will explore manipulating styles in runtime.

• Re-Using Styles for Different Types: the TargetType of the Style can be a parent type of the target object as long as it only sets properties of the parent type.
  So for example the Fill property of both an Ellipse and Rectangle can be styled by using a Style that’s TargetType is set to Shape (as both Ellipse and Rectangle inherit from Shape)
• Inheriting Styles using the BasedOn property: Styles can be inherited from one another using the BasedOn property. Single inheritance is supported and the depth of inheritance is not limited.
• Implicit styling: Implicit styles allow defining a default style for all instances of a given type within the scope of the control. This feature has been introduced in Silverlight 4.
• Style Precedence: Styles are only applied to a property if that property is not animated, has no local value set and has no value set in a template. This precedence is the same as the dependency property precedence.
• Style Setter Precedence: setters specifying the value of the same property may be declared within the same Style. The last one of them has the highest precedence and will be used.

You can read the (much more detailed) full article on my Scott Logic blog. The next part of the series will cover further advanced topics such as using Styles in code behind and exploring the relationship between styles and dependency properties from a practical perspective.

• What are Styles?
  Styles are basically list of property-value pairs. Defining a style consists declaring the TargetType property and the list of Setters.
• Defining Styles in XAML
  Defining styles in XAML is the easiest and most common method. They can either be defined in the Resources section or inline.
• Styles defined in XAML can be referenced in code-behind.
• Altering visual templates of an object doesn’t always end at styling. More powerful way of customizing the look and feel of objects involves using Control Templates and Themes.

You can read the (much more detailed) full article on my Scott Logic blog. This part has meant to be an introduction, the next parts will dig into more advanced Style usage scenarios.