Santiago Palladino

WPF introduced a new concept for managing properties which is dependency properties. Dependency properties can act as standard properties, but also offer a lot more functionality, such as data binding, assignment through resources, setters in styles, and a lot more. They also allow for easy extensibility since they can be declared in different classes than the types they affect, and can be set directly from XAML. Silverlight, of course, has inherited this, yet it has a subtle difference.

In order to define a dependency property for a user control in Silverlight, suppose TestNumber of type int in the control TestControl (those are original names, aren’t they?), you must do the following:

public int TestNumber
{
    get { return (int)GetValue(TestNumberProperty); }
    set { SetValue(TestNumberProperty, value); }
}

// Using a DependencyProperty as the backing store for TestNumber.
// This enables animation, styling, binding, etc...
public static readonly DependencyProperty TestNumberProperty =
    DependencyProperty.Register("TestNumber",
        typeof(int),
        typeof(TestControl),
        new PropertyMetadata(
             new PropertyChangedCallback(TestNumberChanged)));

Looks a bit scary at first, specially if you have to remember all that whenever you want to make a new dependency property. Luckily Visual Studio ships with the propdp code snippet that automatically creates this.

The public property ensures easy access from code to the property, so that you can treat dependency and standard properties exactly the same way. Getters and setters forward the call to the FrameworkElement functions GetValue and SetValue, which receive the property to manage.

As for the property, it is registered statically, by declaring its name, type, owner and metadata. In this last piece is where the difference with WPF relies. While WPF expects an instance of UIPropertyMetadata, which allows you to specify an on-change callback, a default value, forbid animations and a few more things, Silverlight dependency properties receive a PropertyMetadata, which allows you to specify only the callback, not default values.

Nevertheless, there is an easy workaround to supply a default value for these properties as long they are defined for a user/custom control. When you set a value for a control in XAML, the value is set after its constructor is invoked (which makes sense if you think about it). All you have to do then is set the property value in the constructor, and it doesn’t matter whether it is before or after the InitializeComponent call.

In case you are wondering when the control’s constructor is invoked, it is when its parent’s InitializeComponent call is made. What this method does is process the XAML and create all objects specified in it, and set all fields named after the named controls with their correct values.

Since Silverlight 2 Beta 2 introduced the WebClient class, I decided to refactor an application we had by replacing all references to HttpWebRequest with the new client. Its methods seemed much more simple and clear, and I didn’t even need to write a wrapper helper class to make calls to the server. But, as it happens with every refactor, I ran across a few problems.

The first thing I noticed was the fact that I the only method provided by the WebClient to send a stream of data in a POST to the server didn’t return the server’s response. The result parameter in the OpenWriteCompleted event is the opened writable stream, and I didn’t find any way to obtain the server’s response.

So, I ended up using the much simpler UploadString, which does return the response. The only problem is that I needed to serialize some objects, so I built an XmlWriter on top of a StringBuilder, serialized into it, and sent the ToString() of the writer:

XmlSerializer serializer = new XmlSerializer(typeof(T));
StringBuilder builder = new StringBuilder();
XmlWriter writer = XmlWriter.Create(builder);
serializer.Serialize(writer, data);
client.UploadStringAsync(url, builder.ToString());

But this threw an exception on the Java server, stating that it couldn’t deserialize the POSTed object, because "Content is not allowed in prolog". Googling a few minutes it came up that encoding could be the cause, and seeing that the serializer generated UTF-16 code, I decided to go for UTF-8 and see what happened.

serializer.Serialize(writer, data, null, Encoding.UTF8.WebName);

Now came the big surprise. When I ran this code, I got this beautiful exception stating that I shouldn’t set the encoding:

In other words, do not use the serialize method that sets encoding. The full text of the exception is The encoding style ‘utf-8′ is not valid for this call because this XmlSerializer instance does not support encoding. Use the SoapReflectionImporter to initialize an XmlSerializer that supports encoding.

Before you try to use the SoapReflectionImporter, let me tell you that it isn’t included in the Silverlight 2 Beta 2 NET framework.

As a final attempt, I tried simply removing the xml document prolog. Since there isn’t a XmlDocument class either in the framework, I had to do it the old way:

string written = builder.ToString();
written = written.Substring(written.IndexOf('>') + 1,
written.Length - written.IndexOf('>') - 1);

And it worked. It seems that the WebClient was adding an extra header to the xml string I was sending, and therefore the Java web service threw the exception. Whatever the reason, it now works beautifully.

Update: Juan Wajerman pointed out that it is possible to pass XmlWriterSettings to its constructor, and specify there both the encoding and a very useful property named OmitXmlDeclaration, which does exactly what I wanted without needing to rely on the horrible string operations.

XmlSerializer serializer = new XmlSerializer(typeof(T));
StringBuilder builder = new StringBuilder();

using (XmlWriter writer = XmlWriter.Create(builder,
       new XmlWriterSettings { OmitXmlDeclaration = true }))
{
      serializer.Serialize(writer, data);
}

string written = builder.ToString();

Silverlight 2 Beta 2 has introduced a number of fixes, additions and changes to the previous Beta 1 version. As I said in a previous post, I believe the improved error handling and detailed exceptions are among the best improvements, and also the less commented.

There have also been several improvements in Expression Blend, most of them regarding the Visual State Manager (which I’ll describe in a few moments), but Scott Guthrie has already described them flawlessly.

As for a detailed list of changes, you can always refer to MSDN. What I will be focusing in here are all breaking changes that you will encounter when migrating your Beta 1 application to Beta 2, since most of them won’t be noticeable in compile time.

What you will first surely notice after updating to Beta 2 is -obviously- that your code no longer compiles. These are by far the easiests errors to fix. Most of them will be regarding namespaces, or definitions of Dependency Properties, since the signature of the Register method has changed slightly to be more like its WPF equivalent. The DialogResult enum has been replaced by a bool? as the return type of OpenFileDialog, behaviour also shared with WPF.

Fairly easy, isn’t it? Migrating a whole Silverlight application from Beta 1 to Beta 2 hasn’t taken more than a few minutes. However, when you run the application, you will realize that it isn’t that easy.

The first problem you might encounter, if you are using a Web Site Project to run your Silverlight application in an HTML page, is seeing this logo instead of your welcome screen:

This will redirect you to the Beta 1 download page, stating that the application you are trying to open has been developed in an earlier version, even though Visual Studio has already updated the project.

This just requires a correction in the HTML code of the page. Look for a line similar to this one:


<object data="data:application/x-silverlight,"
type="application/x-silverlight-2-b1"
width="100%" height="100%">


Noticed anything? Just replace x-silverlight-2-b1 with x-silverlight-2-b2 and voila. Actually, you should re-generate the whole page, since the javascript function onSilverlightError has changed as well and, more important, the links to download the plugin in case it is missing:


<a style="text-decoration: none;"
href="http://go.microsoft.com/fwlink/?LinkID=115261">
<img style="border-style: none"
src="http://go.microsoft.com/fwlink/?LinkId=108181"
alt="Get Microsoft Silverlight" />
</a>


Now, the application finally runs. However, it is most likely that if you have been playing with control templates (and you should have, since it is there where lies most of Silverlight’s power), some things may appear broken.

Silverlight allows you to completely redefine a control’s visual tree, thus making a button render as a textbox with a calendar floating around it. It is extremely flexible, and worth a whole post in the blog.

Some controls expect certain elements in their visual tree for correct behaviour. For example, a ScrollViewer expects two ScrollBars, one vertical and one horizontal, to handle the scrolling of its contents.

Now, how do you specify inside the control template (the mechanism to override the control’s visual tree) which scrollbar is the horizontal one and which one is the vertical one? You may even have more scrollbars, just for decoration, or to handle some other content. Well, you use a specific x:Name for it. If a ScrollViewer finds a ScrollBar named HorizontalScrollBar in its template, then it assumes it is the one that handles the horizontal scrolling of its content. If the name is something else, then it is just ignored and rendered without any special considerations. After all, it is just a name.

The problem here (and we finally get back to the differences between beta 1 and beta 2) is that those reserved names have changed in beta 2. HorizontalScrollBar in beta 2 was HorizontalScrollBarElement in beta 1. This means you will have to rename most of them everywhere you have used them (luckily, the change is nothing more than removing the ending Element in most cases). And the big problem, is that Visual Studio will not warn you against this, since you are just setting a name. The only clue you will have is that controls you have templated won’t behave correctly.

Last but not least, the introduction of the Visual State Manager has also changed quite a lot of things. Let’s take as an example the check box. Clearly, you want it to render differently if it is checked or not, if it is grayed, if it has focus, if it is right under the cursor, etc. In beta 1, the way to do this was by addind Storyboards to the visual tree’s root with -again- reserved names. These are the storyboards you had to add to control all the different renderings:


<Storyboard x:Key="Normal State" />
<Storyboard x:Key="Checked State">
<Storyboard x:Key="Indeterminate State">
<Storyboard x:Key="MouseOver Unchecked State">
<Storyboard x:Key="MouseOver Checked State">
<Storyboard x:Key="MouseOver Indeterminate State">
<Storyboard x:Key="Pressed Unchecked State">
<Storyboard x:Key="Pressed Checked State">
<Storyboard x:Key="Pressed Indeterminate State">
<Storyboard x:Key="Disabled Unchecked State">
<Storyboard x:Key="Disabled Checked State">
<Storyboard x:Key="Disabled Indeterminate State">


Quite a lot of states. If you are wondering why they are storyboards (since they handle animations), it is because the specified animation is executed whenever you enter the specified state. A bit verbose, but gives you a lot of control.

Now in beta 2 the syntax has changed. Visual States are organized into orthogonal State Groups, and a control is always in one and only one state of each group. Returning to the CheckBox example:

You can now define storyboards for both states and transitions between states of the same group. For example, you may want the MouseOver animation to be different if the control was previously Pressed or Disabled.

This means, however, that you have no control over the transitions between states of different groups, making it less verbose but less powerful at the same time. Suppose you want the checkbox to turn red if it is Disabled and Pressed. In beta 1, you just created a ColorAnimation inside the Disabled Checked State. Now, you have no communication between states of different groups, and can’t determine when both Disabled and Checked states are present.

The idea is to use different ways to identify groups. Focused is usually represented by a dashed border around the control. Checked states by drawing a check (d’oh) inside the box. And common states, such as mouse over or pressed, by changing its color or shade.

This means that there is no way to directly translate what you have done in beta 1 into beta 2 in terms of visual states. Nevertheless, it is far less verbose, and the introduction of the Visual State Manager in Expression Blend allows designers to work easily on this.

As for the syntax, note that you now need to add the System.Windows namespace to add a reference to the VisualStateManager:


xmlns:vsm="clr-namespace:System.Windows;assembly=System.Windows"


And instead of keeping storyboards loosely as resources, you add them inside VisualStateGroups, which are inside the VisualStateManager, which is inside the control’s resources (yeah, everything end up as a resource).


<vsm:VisualStateManager.VisualStateGroups>
<vsm:VisualStateGroup x:Name="CommonStates">
<vsm:VisualStateGroup.Transitions>
<vsm:VisualTransition To="MouseOver" Duration="0:0:0.1" />
<vsm:VisualTransition To="Pressed" Duration="0:0:0.1" />
</vsm:VisualStateGroup.Transitions>
<vsm:VisualState x:Name="Normal" />
<vsm:VisualState x:Name="MouseOver">
<Storyboard>...</Storyboard>
</vsm:VisualState>
</vsm:VisualStateGroup>
...
</vsm:VisualStateManager.VisualStateGroups>


Keep in mind that Visual Studio won’t like the VisualStateManager.VisualStateGroups tag, but it will compile anyway and the application will run smoothly.

As a final issue to take into account, is the handling of mouse events, which has changed favourably to be more like WPF. Jesse Liberty has an excellent post explaining this change, but it sums up to the fact that the Handled property in the arguments of mouse events is taken into account when bubbling (or not) the mouse event; altough the reflector shows that the ListBoxItem never bubbles it.

To sum up, some of beta 2 breaking changes are not shown by Visual Studio after the upgrade, and they have to be searched for manually, which may be a bit annoying. Nevertheless, the huge leap between the two betas in both support, controls and stability makes it worth the effort.

One of the current most interesting technologies around is Microsoft Silverlight, whose intention is to provide a programmer and designer friendly way to develop web UIs. It is basically a subset of Windows Presentation Foundation, although it has a few minor differences that you will surely note along the way.

If you aren’t familiar to WPF either (as I was when I started trying Silverlight), it is a whole new paradigm that intends to replace WinForms. It defines each control through two files: the old .cs file with the code supporting the front-end and a XAML file. The latter is an XML which should be modified by the designer (after the initial square and black-and-white presentation coded by the programmer) to apply all the necessary styles to make it more human-friendly. Needless to say, WPF is much more than this, and it can’t be explained in a mere paragraph.

Back to Silverlight, you may consider it as the little brother of WPF, designed for web applications. A Silverlight plugin in the browser contains the runtime, and it downloads and executes a .xap file with the assemblies of the application being stored in the server. This allows C# code to be executed directly on the client, without needing to translate it to a massive amount of javascript.

However, note that most user-interaction events are restricted to the browser, therefore some very simple events such as double click are not present in Silverlight. Also, the whole NET framework has been stripped of some of its functionality to ensure it can be packaged in the small plugin; and only a few WPF controls are present without their full functionality (although there are plans to release up to a hundred controls in the release version).

The most recent available version is Silverlight 2.0 Beta 2, which offers some improvements from Beta 1. If you are interested in the details, I won’t be listing them here, since there is already an excellent post by Scott Guthrie containing all changes and even an explanation on how to use the new Visual State Manager in Blend.

In my opinion, the best improvement between the two betas is the fact that exceptions are now much more detailed, giving you a clue on where to find the error in the XAML, instead of just getting an “AG_BAD_PARSER_VALUE”. Note, however, that there are still several XAML errors that could be caught on compile-time that won’t show themselves until you run the application.

To sum up, WPF can be regarded as a new UI design paradigm, with Silverlight being a very powerful web based equivalent, and it is worth giving it a shot. But bear in mind that it is still a beta, containing some annoying bugs still waiting to be corrected, and some very useful features that are missing for no apparent reason. I have the intention to do most of my blogging around them.