Custom Software Apps & SharePoint Consulting

Silverlight is not WPF

I’m using Silverlight for the first time. It’s fundamentally the same as WPF in the way code is written, so I was tempted to use a lot of WPF techniques and tricks.

Alas, Silverlight and WPF are not the same.

Here are some of the differences I didn’t expect:

1. No triggers on data changes. You can use Event.Triggers, but that’s about it. Otherwise you need to do everything in codebehind. There is an Expression Blend SDK that includes Behaviors, which give trigger-like functionality.

2. No layout transformations, only render transformations. The difference is that render transformations occur after the layout has been performed and the position of all controls has been fixed. Then the control can be transformed, but it doesn’t effect the layout of anything else. A layout transformation happens before the positions have been calculated, and the new size resulting from the transformation is taken into account when laying out the other controls. There are workarounds, but they are not simple.

3. Weirdly, there is no Visibility. Hidden, to make a control take up space in the layout but not appear. There is Visibility.Visible and Visibility. Collapsed only.

4. No MetadataTypeAttribute for adding attributes to generated types / properties.

5. No x:Static to set a XAML property to a static property of a class. This one sort of mystified me.

6. All WCF services references are generated as asynchronous calls. Whether you want it that way or not. And it can’t be done otherwise. This was a hassle for me- I had an authorization service that needed to return before I could continue processing, and there’s no easy way to block until the service returns.

7. No System.Array.ConvertAll

8. No custom routed events.

Share this post with your friends

Skip to content