Silverlight

Silverlight 2 beta 2 is live!

Laurent Bugnion — Sat, 07 Jun 2008 06:23:40 GMT

Here we go, Silverlight 2 beta 2 can be downloaded and installed! I had the chance to take part to an "insiders" program at Microsoft, and to play with SL2 b2 for a couple of weeks, and it's a good one. You should switch to b2 as soon as you can!

There are obviously incompatibilities between b1 and b2, but much, much less than between the alpha version and b1. We're getting there!!

Silverlight 2 beta 2 will be used to build applications related to the Beijing olympics, so it's going to be a real nature test for that version. As for the final release.... it's still very much hush hush, so let's leave it for now :)

The best place to start is ScottGu's blog. As usual, Scott describes the new features at length, and has links to all the places where you can download the good stuff.

Note that there is also a new version of Blend 2.5 which can be installed next to a "normal" Expression Blend V2. There is supposed to be a new version of Deep Zoom Composer too, but the download seems to be down currently.

Enjoy!!

A short break

Laurent Bugnion — Sat, 31 May 2008 11:34:38 GMT

I am going to take a short break of blogging for a couple of months. The reason is simple: I have been working on a book about Silverlight 2 since September last year, and we are in a phase now where I need to concentrate on that exclusively, and put other activities aside. I might post the occasional article from time to time, but until mid-Summer, it's going to be write write write.

Stay posted for news about the book coming up, and don't delete me from your feeds, it's really only temporary :)

WPF talk this Thursday: "Ultra Rich Interactive Applications"

Laurent Bugnion — Tue, 27 May 2008 12:47:23 GMT

I have been in very much stress lately and hardly had time to post, but I don't forget you, dear readers...

Anyway, this Thursday, I will be talking in a RIA conference organized by the Internet Briefing group here in Zurich, in the World Trade Center. My talk is titled "Ultra Rich Interactive Applications with WPF" and subtitled "When Silverlight is not enough...". I think it's going to be an interesting talk (but obviously I am partial) about the major differences between WPF and Silverlight, and the added richness that WPF provides. I am a big fan of Silverlight, but I have to admit that it's nice going back to the amazing power of WPF sometimes, without having to worry about "is that feature even implemented in Silverlight"?

The talk takes place between 16:30 and 17:30 in the World Trade Center, Leutschenbachstrasse 95, 8050 Zürich. Hoping to see some of you there, maybe!

Silverlight: User Controls with events

Laurent Bugnion — Sat, 26 Apr 2008 19:59:55 GMT

This article is for Silverlight 2 beta 1

Update: Corrado Cavalli translated the example in VB.NET. Thanks Corrado!!

Apparently, one reader had issues declaring events for the User Control example that I posted earlier this week.

He is programming in VB and unfortunately I don't have a lot of experience with VB.NET, so I first created a working example with C#, and my good friend and fellow MVP Corrado Cavalli translated the example in VB.NET (see below).

The big difference between WPF and Silverlight regarding events is that Silverlight doesn't support Routed Events (yet?). To be precise, some events are routed (all input events like MouseLeftButtonDown, KeyDown, etc...

Instead of declaring RoutedEvents in our User Control, we have to resort to standard .NET events then. From a user point of view, it doesn't make a very big difference in the subscribing, but of course these events will not tunnel nor bubble (for a summary of RoutedEvents, bubbling and tunneling in WPF, read this).

The sample here declares a User Control called LeftRightButton, with two buttons, a LeftButton and a RightButton. it also declares two events, a LeftClick and a RightClick. When the RightButton gets clicked, the UserControls catch this event and raises a RightClick event. The same happens with the LeftButton and the LeftClick event.

Declaring new events for any class requires a Handler declaration (a delegate), and then the event declaration itself.

public delegate void ClickHandler(object sender, EventArgs e);
public event ClickHandler RightClick;
public event ClickHandler LeftClick;

The next step is to catch the internal click events, and to raise the corresponding "external" event. Note that in this simplified example, I just re-route the RoutedEventArg for the event. Often, you need to declare your own class inheriting EventArgs, for example to pass additional parameters to the event subscriber.

So if the XAML LeftButton is declared as:

<Button x:Name="LeftButton"
        Click="LeftButton_Click" />

then we have:

void RaiseLeftClick(RoutedEventArgs e)
{
  if (LeftClick != null)
  {
    LeftClick(this, e);
  }
}

Note how we check if the event is null before we raise it. If no one subscribed to the event, LeftClick will be null, and there is a risk for a NullReferenceException to be thrown.

Then only thing that we need to do now is catch the internal click event, and raise the corresponding RightClick or LeftClick event.

private void LeftButton_Click(object sender, RoutedEventArgs e)
{
  RaiseLeftClick(e);
}

The User Control raising these events is located in an external assembly as shown here. I use 4 instances of the User Control in a Silverlight application. This way, we demonstrate how to raise new events, how to catch them in another assembly, and how to handle them.

<controls:LeftRightButton x:Name="ButtonTopLeft"
                          RightClick="LeftRightButtonButton_RightClick"
                          LeftClick="LeftRightButtonButton_LeftClick" />

private void LeftRightButtonButton_LeftClick(object sender, EventArgs e)
{
  LastEventControlNameTextBlock.Text = (sender as LeftRightButton).Name;
  LastEventEventNameTextBlock.Text = "LeftClick";
}

The source code in C# can be downloaded here.

The source code in VB.NET (translated by Corrado Cavalli) can be downloaded here.

Silverlight: Running standalone full trust applications

Laurent Bugnion — Thu, 24 Apr 2008 12:09:29 GMT

Introduction

I guess that it's time to write about it, after making a few people curious at the MVP summit in Seattle. This article is to be taken as a proof of concept, and (I hope) as a way to "motivate" Microsoft to integrate this ability into Silverlight.

As soon as I started playing with Silverlight, I saw the great potential that this technology has. As a RIA technology, it provides extended functionality over the web. As a WPF subset, it allows me to leverage the knowledge I already acquired in the past, and to reuse it for web applications. This in itself makes Silverlight a technology I *have to* learn.

But what if... what if we could use Silverlight to run lightweight .NET applications in standalone mode? A little like Adobe AIR is offering, but with the power of .NET instead of ActionScript. Imagine a small application, running on a small framework, installed in typically 10 seconds.

I posted an article on my site explaining the thought process and giving information about standalone Silverlight applications, their promises and their limitations. For those of you too impatient to read the full article :) you can download a demo and the source code directly from here.

The demo

To install the demo, follow the steps:

Download the Zip file.
Extract the Zip file to a folder on your hard drive.
On Windows: double-click the file "Start.hta".

This starts the MSHTA host, and displays the Silverlight application.

Silverlight application in MSHTA

Enter a directory path in the first textbox, and then click on "Get list of files". This displays the corresponding list in the listbox.
Select a file. Its name is displayed in the second textbox.
You can now modify the file name and press on "Rename".
Enter any file path in the last textbox and press "Does file exist?". A corresponding message is displayed in the status bar.

This last functionality is also available in Mozilla-based browsers, for example Firefox. You can try it by setting Firefox to be your default browser, and then double-clicking the file "index.html" located in the same folder as "index.hta". This starts the application in "file" mode, and you get the same permissions. The other functionalities "Get list of files" and "Rename" are not implemented in Firefox and will raise an error.

Silverlight application in Firefox

Source code

As usual, the source code is available for download. It contains the following projects:

GalaSoft.SL.TestHta: This is the Silverlight application you want to run. It contains an "index.html" file, which should be the start page if you run the application in "F5" or "Ctrl-F5" mode in Studio. Visual Studio runs the HTML file in file mode, so you get a chance to debug the Silverlight code, but unfortunately it is not possible to debug the JavaScript code. When you build the project, a "index.hta" file is automatically created. This is exactly the same as "index.html", but with a different extension. Double-clicking this file in Windows Explorer will start the MSHTA host.
GalaSoft.SL.IO: This is a library defining a new DirectoryInfo and FileInfo classes. These classes mimic the actual System.IO.DirectoryInfo and System.IO.FileInfo classes. They use the class "GalaSoft.SL.IO.ScriptFacade" to channel the full-trust calls to the script code contained in the file "script\gslb.filesystemexplorer.js".
GalaSoft.SL.IO.Test: A Unit Test application for GalaSoft.SL.IO. Written using the Silverlight Unit Test framework and accessing JavaScript as described here. I use this to unit test all my IO classes and methods, including the corresponding JavaScript file.
Note: The console application "GalaSoft.SL.IO.Test.Prepare" must be executed before the unit test is run.
GalaSoft.SL.IO.Test.Prepare: This console application is needed to create a few directories and files in the local drive in order to unit test the library GalaSoft.SL.IO. It requires write-permission to the folder c:\temp. Unfortunately, I don't think that Mock frameworks exist for JavaScript yet.

In normal use, the project GalaSoft.SL.TestHta should be chosen as startup project, and its file "index.html" as startup page. You can modify the application code. If you change the HTML code, the changes will automatically be copied to "index.hta" when you build the application.

Components involved in a standalone Silverlight application

Silverlight: Packing user controls in separate assemblies

Laurent Bugnion — Wed, 16 Apr 2008 12:49:34 GMT

This article is for Silverlight 2 beta 1

There is a common misconception that User Controls in Silverlight must be placed in the assembly from which they are referenced. However, this is not true, you can have user controls in an assembly and use them from another assembly. This is not a direct process, however, so let's see how to proceed:

Preparing the control

Create a new Silverlight 2 application in Visual Studio. In this example, we'll name this application "UserControlsPacking". For this first application, you can choose to generate a test web application, or to use a basic HTML test page.
In the same solution, create another Silverlight application. Let's name it "UserControlsPacking.Controls". Choose the "Generate a HTML test page" option, to avoid creating unnecessary test projects.

In the moment, Silverlight 2 beta 1 has only 2 project templates available: "Silverlight Application" and "Silverlight Class Library". Ideally, we would need a "Silverlight User Control Library", just like there is a "WPF User Control Library" for WPF. This option is not available however, so we will "misuse" an Application template to pack our user controls.

In the application named "UserControlsPacking.Controls", delete the following files: App.xaml, App.xaml.cs, Page.xaml, Page.xaml.cs.
Right-click on the "UserControlsPacking.Controls" project in the Solution explorer, and select "Add / New Item...".
Under "Silverlight", select the "Silverlight User Control" item template.
Implement the new user control, for example by opening the XAML file in Blend, and adding some code.
Note: You should probably delete the "Width" and "Height" property as the very first thing you do in your XAML. Studio fix-codes these properties automatically, but let's be frank, noone wants this in a control.

Using the User Control in Studio

After implementing the user control, now it's time to use it. First we must add a reference to the "UserControlsPacking.Controls" project in the main application project.

Right-click on the "UserControlsPacking" project and choose "Add Reference...".
In the tab "Projects", select the "UserControlsPacking.Controls" project and click OK.

From this moment on, you can use the User Control in the main project. You can either add the User Control in Blend (see below) or in XAML.

In Studio, open the file "Page.xaml".
You need to add a reference to the namespace containing the new UserControl. This gets added as an XML prefix in the UserControl tag.
(Note: Studio assists you there: Simply type "xmlns:control=" and Intellisense will propose you a list of all the XML namespaces, including those located in referenced assemblies).

<UserControl x:Class="GalaSoft.SL.UserControlsPacking.Page"
             xmlns="http://schemas.microsoft.com/client/2007"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:controls="clr-namespace:GalaSoft.SL.UserControlsPacking.Controls;assembly=GalaSoft.SL.UserControlsPacking.Controls"
             Width="400"
             Height="300">

Once this is done, you can use the control in the XAML code, for example:

<Grid x:Name="LayoutRoot"
      Background="White">

  <Grid.ColumnDefinitions>
    <ColumnDefinition Width=".5*" />
    <ColumnDefinition Width=".5*" />
  </Grid.ColumnDefinitions>

  <Border BorderBrush="Magenta"
          BorderThickness="2"
          Padding="5">
    <StackPanel>
      <TextBlock FontSize="15"
                 FontWeight="Bold">Billing:</TextBlock>
      <controls:AddressControl />
    </StackPanel>
  </Border>

  <Border BorderBrush="Magenta"
          BorderThickness="2"
          Grid.Column="1"
          Padding="5">
    <StackPanel>
      <TextBlock FontSize="15"
                 FontWeight="Bold">Shipping:</TextBlock>
      <controls:AddressControl />
    </StackPanel>
  </Border>

</Grid>

Using the control in Blend

Like you would expect, you can also find the User Control in Blend's asset library, even though it is located in an external assembly. To find the control, simply open the asset library (that's the last button down in the Toolbox bar). Then click on the tab "Custom Controls". You should be able to see your user control in the list. Note however that the control sometimes doesn't show up immediately. Make sure that you saved your whole solution in Visual Studio, make sure that you built everything, and try to open the asset library a few times to update the list.

Note that Blend takes care of adding the necessary namespaces to the XAML, so you don't need to worry what we did in the first code snippet above.

Resources

You can download a sample application demonstrating this. Simply open the SLN file in Studio 2008.

Conclusion

User controls are often presented as a way to encapsulate parts of the UI, and much less as a way to reuse UI elements in different projects. This is often what Custom Controls are used for.

However, User Controls are a bit easier to understand. While the "lookless-ness" of a CustomControl is bigger than of a UserControl, while the "canonic" way of creating reuseable controls is to rather use CustomControls, I find myself using UserControls time and time again. It's good to know that you can actually use UserControls very much in the same way that you can use CustomControls. HTH!

De WPF Integratio (About WPF Integration)

Laurent Bugnion — Fri, 11 Apr 2008 20:38:56 GMT

Introduction

I've been posting a lot about Silverlight lately, but hey, here is a WPF post, and about WPF integration, no less.
Note: To fully understand this article, you should have a basic understanding of WPF, styles and templates, triggers, etc...

In my current project at work, I act as WPF Integrator. I am that dude who sits between the designers and the developers, and tries to avoid that they fight too much. Or something. Sometimes it works, sometimes it doesn't, you know how it is with kids. They need their freedom. But I digress.

One important task of a WPF Integrator is (drum roll) WPF integration. For us, this operation usually occurs when we have a design iteration. The way we create application components is (roughly) the following:

The Developer creates the component in Visual Studio. The component is composed of a main assembly (EXE or DLL), containing "functional XAML" and source code (code-behind), and a "Skins" DLL containing XAML resource dictionaries.
(Note: Because we don't want any source code into the "Skins" DLL, and to avoid circular references, we actually have a 3rd assembly called "Converters". As the name shows, this assembly contains the converters (and other helper classes) that are referenced from the Skins DLL).
Together with the WPF Integrator, they create a "raw" UI. That means a basic layout made of "functional XAML", according to the wireframes created by our user experience engineers.
(Note: "functional XAML" is the XAML code that is not strictly doing look&feel. For example, a Button tag is functional XAML, while the style and template it uses are "design XAML").
The WPF Integrator prepares the Skins DLL by exporting all styles to it (using Blend). We follow certain guidelines in naming all the components (styles, templates, DLL names, etc...) and also in the structure of the styles and templates (see below).
The Developers start what they do best, Developing. Meanwhile, the Designer do what they do best (let me hear you:) Designing! This is the Design iteration I was referring to before.
(Note: The Developer *only* works in the main assembly. The Designer *only* works in the Skins assembly.
If the Designer needs to change something in the main assembly, they contact the WPF Integrator to coordinate.
Similarly, if the Developer needs to change something in the Skins DLL, they contact the WPF Integrator to coordinate.
When a set of features are complete, the Developers' and Designers' work is integrated and tested.

Typically, we integrate the design to the application during design workshops, where a couple of Designers and Developers (and the WPF Integrator) sit together and work together, pretty much in an Extreme Programming spirit. These workshops are very intense and interesting, and usually allow fast progress in the application's look&feel.

Conventions, file structure, naming

A control refers to a Style which in turn refers to a Template (this is to facilitate the designers' job in Blend).
A control does *not* set its template directly, but always through a style.
If triggers are needed in the main assembly, the local style refers to a "BasedOn" style located in the Skins DLL.
A Style key is named like the control it refers to, suffixed with "Style". For example "MySpecificButtonStyle" or "ListBoxStyle" (for all ListBoxes), etc...
A Template key is named like the control it refers to, suffixed with "Template". For example "MySpecificButtonTemplate" or "ListBoxTemplate" (for all ListBoxes), etc...
(note: We use the "Template" suffix for ControlTemplate and DataTemplate).
The skin resources for a given control are stored in a resource dictionary file with the "Skin" suffix. For example, the control "MyUserControl"'s resource dictionary is named "MyUserControlSkin.xaml".

These guidelines help the designers to understand which Style and Template belong to which control. Note that Blend makes that task easier by allowing to navigate from the main assembly to the Skins assembly with a succession of clicks.

Typical Designer workflow

The very first task a designer must do when he gets the code is to understand its structure. This is where the conventions mentioned above help. Typically, they work this way:
(Note: You can download a sample application here, open the SLN file in Blend, and then open the main window (Window1.xaml))

Open the application's main window in Blend and check the logical tree.
If a user control is found, right-click on it and choose "Edit control" (fig 1). This opens the User Control XAML file in Blend.
(Of course, this fails if the User Control's source code is not available).
For any control they want to skin, select the control, and then choose the menu "Object / Style" (fig 2 and 3).
At this point, the style chosen can be local (for example if the Developer need to use a Trigger, etc. See listing 1). The Designers are trained to check the name of the file in which they are currently located (in Blend). If the file is named without a "Skin" suffix (for example MyPlugIn.xaml), they may not edit it. In that case, they look for a BasedOn style (fig 4). If they are currently located in a file with a "Skin" suffic (for example "MyPlugInSkin.xaml", then they may edit it (fig 5).
Once in the Style, they can select the context menu "Edit Control Parts (Template) / Edit Template". This opens the Control Template in Blend, where they can rework to look&feel of the control completely (including triggers, animations, etc...)

Figure 1: Edit control

Figure 2: Selecting a control

Figure 3: Edit style

<Button Content="GO"
        Grid.Column="1"
        Click="GoButton_Click">
  <Button.Style>
    <Style TargetType="Button"
           BasedOn="{StaticResource RoundButtonStyle}">
      <Setter Property="IsEnabled"
              Value="True" />
      <Style.Triggers>
        <DataTrigger Binding="{Binding ElementName=DirectoryNameTextBox,
                                       Path=Text}"
                 Value="{x:Static sys:String.Empty}">
          <Setter Property="IsEnabled"
                  Value="False" />
        </DataTrigger>
      </Style.Triggers>
    </Style>
  </Button.Style>
</Button>

Listing 1: Local style using a Trigger, Based On a skin style

Figure 4: Edit "based-on" style

Figure 5: Editing the style in the Skin file

Note: Here we see the advantage of setting the "Template" property in the Style instead of directly in the control: The Designer can see the "shape" of the control already in Blend, without having to rebuild.

Figure 6: Editing the template in the Skin file

The importance of Blend

This workflow would fail miserably without Blend. It can never be repeated often enough: You should keep your application Blendable! (as long as possible). Blend will fail to represent the UI in some circumstances. For example, if your application connects to a COM based component, this is something that Blend cannot handle. Similarly, if your application uses any kind of network service to get data, Blend won't be able to represent this data. This is where the MVVM (Model - View - ViewModel pattern comes handy: By enforcing a data-driven UI, you give the developer the possibility to create "design-time" data, i.e. data which is only used when the application runs in Blend (or in the Visual Studio WPF designer). I could talk about that for hours, and this jumps the scope of this post, but you can read more info about MVVM here:

John Gossman's blog.
Dan Crevier's blog.
Josh Smith's excellent article at CodeProject
Dr WPF's new Software Architecture Pattern: M-V-poo.
My presentation at TechDays 2008 in Basel (slides, source code).
And many more places on the web...

Using WinMerge as an integration tool

During these integration phases, I use WinMerge a lot. The reasons for using this merging tool are multiple:

It is probably the best merging tool currently available for Windows (if someone disagrees, don't hesitate to comment below!!).
Our Designers don't work in our source control infrastructure. They get a copy of the code, refactored as a standalone application. This allows them to test the application easily without having to install a whole networking system (our application is following a Service Oriented Architecture). The aplication they get features a test mode, allowing them to simulate certain conditions (again, see my TechDays talk and the source code for details). Because they work disconnected from the source control, a merging operation is needed.
The merging steps give me a good occasion to review the Designers and Developers work, and to understand it. This is an additional step towards code consistency and code quality (4 eyes review principle).

WinMerge is simply amazing, a must-use tool for a WPF Integrator (at least if you work according to a similar workflow as we do). It is free (amazing, when you see the quality of this tool), was clearly developed by people who needed such a tool and decided to create it (according to the "eat your dog food" idea), and can even be integrated into your favourite source control framework (yes, even ClearCase, which we are forced to use). You can compare folders, binary files, text files with a very clear user interface. All merging operations can be performed using the keyboard only, which is extremely ergonomic. Honestly, I love that tool.

By the way, I didn't mention it yet, but you can also edit both files you are comparing in WinMerge, and save both of them.

WinMerge, merging tool

Conclusion

Much has been written about the Designer-Developer workflow, the WPF Integrator role, the MVVM (or MV*) pattern, etc... In our project, we have the chance to use these principles in a real life situation. I can honestly say, I rarely had so much fun developing software ever. The only thing I can think of that made (almost) as much fun was the big ASP.NET project I worked on prior to this one. The Integrator role is a great place to be.

(Note: I also file this under Silverlight because WinMerge is also very useful for Silverlight integration, even though the Style and Template system is not as rich as in WPF yet).

Silverlight unit testing and JavaScript

Laurent Bugnion — Sat, 05 Apr 2008 15:49:31 GMT

I am currently writing a Silverlight class library which I want to use in a project, and decided to try Test Driven Development for this class. This is a really nice way to work, and the Silverlight development team made this very easy by providing a unit test framework easy to integrate into Visual Studio 2008.

(Note: You cannot simply use the built-in unit test framework, because a non-Silverlight application cannot reference a Silverlight class library).

To find information about where to download and how to install the Silverlight unit test framework, check this post.

Communicating with JavaScript

The only issue with the Silverlight unit test application is that it uses a default HTML test page to instantiate the Silverlight control. If your class library contains one or more JavaScript code files that it interacts with, the test will fail, because the JavaScript file cannot be found. Thankfully, this is quite easy to change:

Start by creating the Silverlight class library that you want to work on.
In the same solution, in VS2008, create a Silverlight unit test application.
(note: Typically I name this test application [MyClassLibrary].Test where [MyClassLibrary] is the name of the class library you want to test).
In the test application, add a reference to the Silverlight class library that you want to test.
Do not add any test at this time!
Right-click on the Silverlight test application and select "Set as Start-Up Project".
Run the application. Don't worry about the test result so far.
In the web browser, select the menu "View source":
Copy the whole HTML code.
In Visual Studio, right-click on the Silverlight test application and choose "Add / New Item...".
Select a HTML page, rename it "index.html".
Select the whole HTML code in index.html and replace it with the HTML code you have in the clipboard.
Modify the Silverlight control's "source" attribute to prepend the "ClientBin" folder.

This step is needed because of the placement of the generated TestPage.html. This page is generated inside the ClientBin folder, as well as the XAP file. Since our index.html is located outside of the ClientBin folder, we need to update the "source" attribute. This is a one-time only operation

From the Silverlight class library, drag and drop the JavaScript code file that your class library will interact with. A copy gets added to the test application.
In the file "index.html", add a reference to that JavaScript file in the HEAD section.
Right click on "index.html" and select "Set as Start Page".

That's it! Now you can write a few tests involving classes from your class library. The JavaScript interaction is working, because the JavaScript file your class communicates with is found in the same folder as index.html.

There are a few caveats though:

If you modify the JavaScript code file, you must remember to udpdate the copy located in the test application too!
You cannot debug the JavaScript code, because the test application is a Silverlight application, and if you run the debugger, it will attach to the Silverlight code only, not to the JavaScript code.

To illustrate this, I published a very basic Silverlight class library with JavaScript interaction and unit test application. You must install the Silverlight unit test framework first!

Important: After you download the test code, make sure that you set "GalaSoft.SL.MyClassLibrary.Test" as startup project, and "index.html" as start page!!

Silverlight Bug: Transforms and OpacityMask

Laurent Bugnion — Fri, 04 Apr 2008 14:00:11 GMT

Introduction

In WPF, one of the best know effects is the "reflection" effect, where a scene reflects itself dynamically. It's a very cool feature, because it's really easy to realize, and it allows to reflect images, but also videos or other User Interface scenes. The key to this is to use a VisualBrush. Silverlight is not exactly as powerful as WPF, and doesn't have VisualBrush, but it has ImageBrush and VideoBrush, both of them allowing cool media reflection effects (these brushes can also be used for other things!).

The key to making a reflection is placing a picture (or a video), and underneath it, an element (typically a Border). Then, you set the background of this element (Border.Background) to an ImageBrush (or a VideoBrush) pointing to the source that you want to reflect. To make the reflection look more lifelike, however, you want to skew it (because the surface you reflect is forming an angle with the reflecting element); also, you typically use an OpacityMask and make it look as if the reflection was progressively disappearing on a non-perfect surface. Life is not perfect, people, so a perfect reflection doesn't look lifelike.

The issue

However, when creating such an effect, I noticed an issue causing skewed elements with an OpacityMask to disappear completely. The following code shows the problem:

<Grid>
  <Grid.ColumnDefinitions>
    <ColumnDefinition Width="200"/>
    <ColumnDefinition Width="*"/>
  </Grid.ColumnDefinitions>
  <Grid.RowDefinitions>
    <RowDefinition Height="100"/>
    <RowDefinition Height="*"/>
  </Grid.RowDefinitions>
  <Border Background="Red">
    <Border.OpacityMask>
      <LinearGradientBrush EndPoint="0,1" StartPoint="0,0">
        <GradientStop Color="#FFFFFFFF" Offset="0"/>
        <GradientStop Color="#00FFFFFF" Offset="1"/>
      </LinearGradientBrush>
    </Border.OpacityMask>
    <Border.RenderTransform>
      <SkewTransform AngleX="30" AngleY="0"/>
    </Border.RenderTransform>
  </Border>
</Grid>

Skewed Border, OpacityMask, Silverlight

Skewed Border, OpacityMask, WPF

Notes

Here are a couple of notes about this:

I simplified the code as much as possible to display the issue. Obviously this is not a reflection anymore, but I stumbled upon the issue when creating a reflection.
The issue is visible in Blend and also if you run the application.
This issue is not limited to Borders. It also occurs if you replace the Border with a Grid, for example.
The issue also occurs with other Transforms. Replacing the SkewTransform with a RotateTransform will reproduce the issue.
If you don't transform the element, the issue does not occur.
If you remove the OpacityMask, the problem does not occur.
If you give a Width and a Height to the element, the problem does not occur.
The same code in WPF runs correctly.

Silverlight 2 beta 1: ScrollViewer with auto-layout crashes both IE and FF

Laurent Bugnion — Mon, 31 Mar 2008 20:58:46 GMT

Update 2: The Silverlight team at Microsoft was able to reproduce the bug, and it has been entered in the bug database. Thanks all for your precious help!!

Update: Apparently this bug is not consistently reproducible. If you get the bug, please enter a comment with your system information. I was able to reproduce on a number of machines and OS, but on some other PCs it works just fine.

Here is an interesting one:

<UserControl x:Class="GalaSoft.SL.ScrollViewerNoCrash.Page"
             xmlns="http://schemas.microsoft.com/client/2007"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Height="300">

  <Grid x:Name="LayoutRoot"
        Background="Green">

    <Grid.RowDefinitions>
      <RowDefinition Height="*" />
      <RowDefinition />
    </Grid.RowDefinitions>

    <ScrollViewer Grid.Row="1"
                  HorizontalScrollBarVisibility="Auto"
                  VerticalScrollBarVisibility="Disabled">

      <StackPanel Orientation="Horizontal"
                  Height="150">

        <Border Margin="10,5,10,5"
                BorderBrush="#FFA9A899"
                BorderThickness="2,2,2,2">
          <Image Source="pic1.png"
                 Stretch="Fill" />
        </Border>
        <Border Margin="10,5,10,5"
                BorderBrush="#FFA9A899"
                BorderThickness="2,2,2,2">
          <Image Source="pic2.jpg"
                 Stretch="Fill" />
        </Border>

      </StackPanel>
    </ScrollViewer>
  </Grid>
</UserControl>

The code above crashes both Internet Explorer and Firefox (on Windows) when you resize the browser window to let the horizontal scrollbar appear in the scrollviewer. I didn't test other platforms.

On the other hand, the following code works:

<UserControl x:Class="GalaSoft.SL.ScrollViewerCrash.Page"
             xmlns="http://schemas.microsoft.com/client/2007"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Height="300">

  <Grid x:Name="LayoutRoot"
        Background="Red">

    <Grid.RowDefinitions>
      <RowDefinition Height="*" />
      <RowDefinition Height="150" />
    </Grid.RowDefinitions>

    <ScrollViewer Grid.Row="1"
                  HorizontalScrollBarVisibility="Auto"
                  VerticalScrollBarVisibility="Disabled">

      <StackPanel Orientation="Horizontal">

        <Border Margin="10,5,10,5"
                BorderBrush="#FFA9A899"
                BorderThickness="2,2,2,2">
          <Image Source="pic1.png"
                 Stretch="Fill" />
        </Border>
        <Border Margin="10,5,10,5"
                BorderBrush="#FFA9A899"
                BorderThickness="2,2,2,2">
          <Image Source="pic2.jpg"
                 Stretch="Fill" />
        </Border>

      </StackPanel>
    </ScrollViewer>
  </Grid>
</UserControl>

Did you spot the difference? The first Grid (the one that crashes) has the second row's height set to 150, while the ScrollViewer and its children are all set to Auto. In the second one (the one that works), the Grid is set to Auto, while the StackPanel inside the ScrollViewer has its Height set to 150. The workaround is good enough for now, but I hope it'll get corrected because I like to layout my grids and then let the auto layout take care of the rest.

Note that both versions work fine in WPF.

Resources

Test the crash and non-crash case.
Download the source code.