Jeff Prosise's Blog

Silverlight 4's New INavigationContentLoader Interface

jprosise — Mon, 08 Feb 2010 13:37:00 GMT

One of the extensibility points added to the run-time in Silverlight 4 is the new INavigationContentLoader interface, which allows applications that use Silverlight's navigation framework to take control of page loading. In Silverlight 3, navigation URIs had to target XAML files containing Silverlight pages. In Silverlight 4, a navigation URI can target anything—a class name, a Web service that provides page content dynamically, or a XAML file contained in a remote XAP, for example—as long as an INavigationContentLoader implementation is present to support it.

David Poll has blogged extensively about INavigationContentLoader and about the different scenarios in which it can be used. Here, for example, is a great post on using a custom content loader to load pages from XAPs that are downloaded on demand. Here's another that demonstrates how to use a custom content loader to authorize access to a page before navigating to it. It seems there is no end to the purposes that INavigationContentLoader might serve.

To demonstrate the bare-bones basics of INavigationContentLoader, I implemented one that serves a simple purpose: it appends ".xaml" to the file names of the pages targeted by navigation URIs. Rather than declare your Frame control and URI mappings this way:

<nav:Frame x:Name="Main" Source="Home">

<nav:Frame.UriMapper>

<map:UriMapper>

<map:UriMapping Uri="" MappedUri="/Index.xaml" />

<map:UriMapping Uri="Home" MappedUri="/Index.xaml" />

<map:UriMapping Uri="Detail/{id}" MappedUri="/Detail.xaml?id={id}" />

</map:UriMapper>

</nav:Frame.UriMapper>

</nav:Frame>

With my CustomContentLoader class, you do it this way instead:

<nav:Frame x:Name="Main" Source="Home">

<nav:Frame.UriMapper>

<map:UriMapper>

<map:UriMapping Uri="" MappedUri="/Index" />

<map:UriMapping Uri="Home" MappedUri="/Index" />

<map:UriMapping Uri="Detail/{id}" MappedUri="/Detail?id={id}" />

</map:UriMapper>

</nav:Frame.UriMapper>

<nav:Frame.ContentLoader>

<local:CustomContentLoader />

</nav:Frame.ContentLoader>

</nav:Frame>

Note the new ContentLoader property on the Frame control, which allows you to replace Silverlight's default content loader with a custom content loader. The default content loader is an instance of PageResourceContentLoader, which loads pages from local XAML files. My CustomContentLoader wraps an instance of PageResourceContentLoader and appends ".xaml" to target URIs before delegating to PageResourceContentLoader to do the actual loading. Here's the source code:

public class CustomContentLoader : INavigationContentLoader

{

private PageResourceContentLoader _loader = new PageResourceContentLoader();

public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri,

AsyncCallback userCallback, object asyncState)

{

return _loader.BeginLoad(AddFileNameExtension(targetUri),

currentUri, userCallback, asyncState);

}

public bool CanLoad(Uri targetUri, Uri currentUri)

{

return _loader.CanLoad(AddFileNameExtension(targetUri), currentUri);

}

public void CancelLoad(IAsyncResult asyncResult)

{

_loader.CancelLoad(asyncResult);

}

public LoadResult EndLoad(IAsyncResult asyncResult)

{

return _loader.EndLoad(asyncResult);

}

private Uri AddFileNameExtension(Uri uri)

{

int index = uri.OriginalString.IndexOf('?');

if (index == -1) // No query string; append extension

return new Uri(uri.OriginalString + ".xaml", UriKind.Relative);

else // Insert extension before query string

return new Uri(uri.OriginalString.Insert(index, ".xaml"), UriKind.Relative);

}

Note the asynchronous design of INavigationContentLoader. When you implement it, you often have to implement IAsyncResult, too. I didn't have to in CustomContentLoader because I used the IAsyncResult returned by PageResourceContentLoader. While the asynchronous design complicates matters when writing a synchronous loader, it's perfect for content loaders that load pages using Silverlight's asynchronous networking stack.

This is a trivial example, but it still demonstrates the power of INavigationContentLoader. The upshot is that in Silverlight 4, navigation URIs no longer have to target local XAML files, but can be virtualized instead. Look for this to come in handy not only for application developers, but for future versions of Silverlight as well.

Silverlight 4's New Notification Windows

jprosise — Sat, 09 Jan 2010 13:44:00 GMT

Silverlight 4 includes a slew of features designed to make out-of-browser applications richer. One of those features is notification windows, also known as “toast” windows. This feature is available to all OOBs, regardless of whether they are trusted. It is not available to applications that run inside the browser.

A notification window is one that pops up in the lower right corner of the screen, similar to the ones that Outlook uses to notify users about incoming e-mails. (On the Macintosh, notification windows appear at the top of the screen rather than the bottom.) Notification windows are normally used to let the user know something important has happened. A classic use for them is to inform the user that an updated version of an out-of-browser application is available when the OOB is launched from the desktop or Start menu:

This notification window was created by first declaring a user control named UpdateNotification that contained the following content:

<Border.Background>

<LinearGradientBrush StartPoint="0.5,0.0"

EndPoint="0.5,1.0">

</LinearGradientBrush>

</Border.Background>

<Border.Effect>

<DropShadowEffect BlurRadius="4" ShadowDepth="4"

Opacity="0.4" />

</Border.Effect>

<TextBlock Text="Update Available" FontSize="12"

FontWeight="Bold" Foreground="White" Margin="4" />

</Border>

<Image Source="Images/Update.png" Width="32" Height="34"

Stretch="Fill" Margin="4" VerticalAlignment="Top" />

<TextBlock Width="240" Text="An updated version..."

FontSize="11" Foreground="#FF202020" TextWrapping="Wrap"

Margin="4" />

</StackPanel>

</Border>

</Grid>

Then it was displayed by creating an instance of System.Windows.NotificationWindow, instantiating the user control and assigning it to the NotificationWindow’s Content property, and calling NotificationWindow.Show:

NotificationWindow win = new NotificationWindow();

UpdateNotification un = new UpdateNotification();

win.Width = un.Width;

win.Height = un.Height;

win.Content = un;

win.Show(10000);

The parameter passed to NotificationWindow.Show is a time-out parameter that specifies how long the notification window will be displayed—in this case, 10 seconds. If desired, you can call NotificationWindow.Close to close the notification window early—for example, in response to a mouse click.

Another new feature available only to OOBs is the ability to interact with host windows. In Silverlight 3, out-of-browser applications had limited control over their environment. It was not possible, for example, for an OOB to resize the window in which it was hosted.

This changes in Silverlight 4 with the addition of the System.Windows.Window class and the new Application.MainWindow property. An out-of-browser application can get a reference to its window through the MainWindow property, and it can use Window properties and methods to interrogate and even modify the host window. The following code snippet resizes the host window programmatically:

Window win = Application.Current.MainWindow;

win.Width = 1024;

win.Height = 768;

The Window class also features properties named Left and Top for repositioning host windows, WindowState for minimizing, maximizing, and restoring host windows, and TopMost for controlling the host window’s topmost state. And it includes an Activate method for bringing a host window to the foreground and assigning it the focus.

Silverlight 4's New Managed Extensibility Framework

jprosise — Mon, 04 Jan 2010 14:46:00 GMT

One of the less-talked-about features of Silverlight 4 is the new Managed Extensibility Framework, or MEF. MEF has been evolving on CodePlex for a while now. It's slated to be integrated into .NET 4.0 and Silverlight 4, and as such is something with which developers should be familiar.

As its name implies, MEF is a framework for building extensible applications. It provides infrastructure for loose coupling between components and can be used to create composable applications—apps that pull together "parts" from various locations to compose an aggregate to present to the user. One of the key concepts in MEF is that of the catalog, which tells MEF where to look for parts that make up an application. An application can import parts from the catalog with [Import] attributes, and parts themselves can use [Export] attributes to expose themselves to importers. That's the big picture, and of course it ignores hundreds of little details, but understanding these core concepts is a big help in understanding MEF as a whole.

To demonstrate how Silverlight developers might use MEF in a somewhat real-world scenario, I built a sample application named MEFDemo, which you can download from Wintellect's Web site. MEFDemo is an extensible Silverlight 4 image editor. You load photos into it through an OpenFileDialog, and then you click buttons to apply filters of various types to the photos. Here's MEFDemo showing a photo I snapped in the Vatican a few years ago:

And here's how it looked after I clicked the Blur button a few times and then embossed the image:

Out of the box, MEFDemo offers three image filters: a grayscale filter, a blur filter, and an embossing filter. Because the filters are MEF plug-ins, you can easily write filters of your own and plug them into the application.

One of the filters—the grayscale filter—is embedded in the main application. It's found in GrayscaleFilter.cs and it implements an interface named IImageFilter:

public class GrayscaleFilter : IImageFilter

{

public string Label

{

get { return "Grayscale"; }

}

public void Execute(WriteableBitmap bitmap)

{

...

}

IImageFilter is defined a separate project named ImageFilterContract and is decorated with an [InheritedExport] attribute, which means all types that implement the interface should be exported by MEF:

[InheritedExport]

public interface IImageFilter

{

void Execute(WriteableBitmap bitmap);

string Label { get; }

}

The other two filters are exported from a separate project named ConvolutionFilters. Because the project type is Silverlight Application, not Silverlight Class Library, building the solution places two XAP files in the Web site's ClientBin folder: MEFDemo.xap, which contains the main application, and ConvolutionFilters.xap, which contains BlurFilter and EmbossFilter. These filters, too, implement IImageFilter and are automatically exported from the XAP as a result of the [InheritedExport] attribute.

In MEF terminology, the exported image filters are "parts." Which begs the question: how and where do the parts get imported?

Look in MainPage.xaml.cs and you'll find the following property declaration:

[ImportMany(AllowRecomposition = true)]

public ObservableCollection<IImageFilter> Filters { get; set; }

The [ImportMany] attribute tells MEF to look for all exported parts that implement IImageFilter and to populate the ObservableCollection with references to those parts. In MainPage's constructor, a single line of code binds the ObservableCollection to an ItemsControl to produce buttons representing the imported image filters. The ItemsControl uses the following item template to create the buttons:

<ItemsControl.ItemTemplate>

<Button Content="{Binding Label}" Width="96" Height="32"

Margin="0,12,12,12" Tag="{Binding}" Click="OnExecuteFilter" />

</DataTemplate>

</ItemsControl.ItemTemplate>

The text on the face of each button comes from the associated image filter's Label property, and the Tag property holds an IImageFilter reference to the filter itself. When a button is clicked, it's a simple matter to retrieve the IImageFilter reference and use it to invoke the filter:

IImageFilter filter = (sender as Button).Tag as IImageFilter;

filter.Execute(_bitmap);

With MEF, we can export parts and we can import parts. But how does MEF know where to look for parts to satisfy our imports? The answer is found in MainPage's constructor:

// Create a catalog and add this XAP to it

PackageCatalog catalog = new PackageCatalog();

catalog.AddPackage(Package.Current);

// Download additional XAPs and add them to the catalog

Package.DownloadPackageAsync(new Uri("ConvolutionFilters.xap", UriKind.Relative),

(s, p) => catalog.AddPackage(p));

// Pass the catalog to the MEF and compose the parts

var container = new CompositionContainer(catalog);

container.ComposeParts(this);

The first line creates a package catalog. The second line adds the current package (MEFDemo.xap) to the catalog, which allows MEF to find the GrayscaleFilter class exported from MEFDemo.xap. The third line initiates an asynchronous download of ConvolutionFilters.xap and adds it to the catalog when the download completes. This allows MEF to find the BlurFilter and EmbossFilter classes in that XAP. Adding image filters to the application is as simple as placing additional XAP files containing the filters in ClientBin and adding one line of code per XAP to download the package and add it to the catalog. Once filters are exported and added to the catalog, buttons representing them will automatically show up in the UI.

This example demonstrates the basics of MEF, but it could go even further. For example, MEF allows you to attach metadata to parts, and to read that metadata without instantiating the parts. Rather than use a Label property to expose text for buttons, image filters could use metadata instead. Glenn Block of Microsoft discusses metadata and lazy loading of imported types in Building Hello MEF Part II. Glenn's blog is a great source of information on MEF, as is Jeremy Likness's blog, which is currently exploring the integration of MEF and Prism. In addition, Mike Taulty has posted a great series of video tutorials on Silverlight MEF on Channel 9.

MEF makes composability a first-class citizen in Silverlight, and it's going to be interesting to see how much of an impact it has on Silverlight design and development. One thing's for sure: there has never been a more exciting time to be a Silverlight programmer!

Silverlight 4's New HTML Hosting Support

jprosise — Tue, 22 Dec 2009 17:12:00 GMT

Another of the new capabilities that Silverlight 4 brings to the platform is the ability to host HTML content inside a Silverlight control. This support isn't limited to static HTML content; the content can be interactive and can include script. It can even be Flash content or content that includes other Silverlight controls.

To host HTML content in Silverlight, you can use either a WebBrowser control or an HtmlBrush. One way to display HTML content is to fire up a WebBrowser control and point it to a URL:

Another way to do it is to call NavigateToString and pass a string of content to the WebBrowser control:

WebBrowserControl.NavigateToString("<h1>Hello, Silverlight</h1>");

HTML hosting is not available to in-browser apps (it applies to out-of-browser applications only), and if an OOB lacks elevated permissions, it can only display content that comes from the same domain as the Silverlight application. However, you can use a little trick to display cross-domain content in OOBs that run without elevated permissions—simply pass an IFRAME targeting the remote content to NavigateToString:

WebBrowserControl.NavigateToString("<iframe src=\"http://www.bing.com\" style=\"width: 100%; height: 100%\"></iframe>");

You can render HTML content with HtmlBrush, too. The following XAML snippet paints a Rectangle with content retrieved from Bing:

<Rectangle.Fill>

</Rectangle.Fill>

</Rectangle>

One difference between WebBrowser and HtmlBrush is that the former displays "live" content, while the latter does not. Another difference is that HtmlBrush can have transforms applied to it, while WebBrowser cannot. For snazzy visual effects involving HTML content like the HTML puzzle demoed at the PDC, you'll probably find yourself using HtmlBrush. To display live, interactive content, you'll find WebBrowser more useful instead.

One of the really cool things about the WebBrowser control is that you can use its InvokeScript method to call JavaScript functions in content hosted by the control. Conversely, JavaScript hosted inside a WebBrowser control can use window.external.Notify to raise ScriptNotify events that can be handled in C#.

To demonstrate why this might be useful (and how it works), I built a sample application that plays YouTube video using YouTube's API player and that uses the player's JavaScript API to drive the video playback from C#. The application runs as an OOB and requires elevated permissions:

The video that plays in the application is one I uploaded to YouTube; it shows one of my RC jets getting a workout at a recent jet meet near Atlanta, GA. You can download the app and install it on your PC to try it out. Don't forget that it has to run outside the browser.

The application uses a WebBrowser control to host the YouTube player. The content is stored in a text file packaged as a loose file inside the XAP file. It's extracted from the XAP with Application.GetResourceStream and passed to the WebBrowser control via NavigateToString:

// Read the HTML content from the XAP

StreamResourceInfo sri = Application.GetResourceStream

(new Uri("YouTubePlayer.txt", UriKind.Relative));

StreamReader reader = new StreamReader(sri.Stream);

string content = reader.ReadToEnd();

// Feed the content to the WebBrowser control

Player.NavigateToString(content);

The content itself includes a mix of HTML and JavaScript (mostly JavaScript). The script instantiates the YouTube player, forwards certain events from the player to the application so they can be handled in C#, and provides a thin JavaScript API layer that the application calls via InvokeScript to control playback of the video. For example, when the user clicks the Play, Pause, and Stop buttons, the application uses InvokeScript to call script funtions named play, pause, stop, and cue:

private void OnPlay(object sender, RoutedEventArgs e)

{

Player.InvokeScript("play");

}

private void OnPause(object sender, RoutedEventArgs e)

{

Player.InvokeScript("pause");

}

private void OnStop(object sender, RoutedEventArgs e)

{

Player.InvokeScript("stop");

Player.InvokeScript("cue", "df6x4U0u7iQ");

}

Similarly, when the state of the player changes—for example, when video playback begins or ends—script inside the control uses window.external.Notify to fire a ScriptNotify event in C# and activate a handler that updates the visual states of the buttons:

function onYouTubePlayerStateChange(state) {

// Ask the Silverlight control to update the YouTube video player

var state = document.getElementById("apiplayer").getPlayerState();

window.external.Notify('Update:' + state.toString());

}

The end result is an application that demonstrates key features of the WebBrowser control and does something interesting, too. Merry Christmas and Happy Holidays!

Silverlight's Big Image Problem (and What You Can Do About It)

jprosise — Thu, 17 Dec 2009 17:46:00 GMT

Quick: Can you spot the problem with these three lines of code?

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

TheImage.Source = bi;

These statements create an image from a stream of PNG or JPG image bits and display the image by assigning it to a XAML Image object named TheImage. It's boilerplate code used to display images read from the local file system or obtained from a service. And while there's nothing inherently wrong with the code itself, you'll want to think carefully before including it in any Silverlight application.

I call it "Silverlight's Big Image Problem." Not the kind of image problem a movie star might suffer, but an inherent memory-consumption problem when dealing with large bitmap images in Silverlight.

The problem manifests itself when you handle large images in large numbers. The My Pictures Viewer that I blogged about yesterday is a case in point. When a user running the application selects a folder containing one or more image files, the viewer displays clickable thumbnail versions of the images. The problem is that because Silverlight's BitmapImage class consumes massive amounts of memory (up to 40 or 50 MB per image for a typical 2 to 3 MB digital photo), you simply can't have too many instances extant at once. But to create a thumbnail, you first need a BitmapImage that wraps the entire image. You might create a thumbnail by assigning the BitmapImage to an Image object that measures just 100 by 100 pixels, but if the original image measures 4,000 by 4,000 pixels, it's the latter figure you pay the price for.

To demonstrate, I wrote a simple test harness that you can easily duplicate yourself. I began with an app that pops up an OpenFileDialog and lets the user select an image file from his or her hard disk. Once the image file is selected, the application generates a thumbnail version of the image and adds it to the scene. Then it generates another thumbnail, and then another, and so on and so forth until Silverlight throws an out-of-memory exception. Here is the helper method that I initially used to generate the thumbnails:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Width = cx;

image.Height = cy;

image.Source = bi;

return image;

}

And here's what happened when I ran the application and selected a 3,648 x 2,736 JPG with a file size of 2.1 MB:

So get this. The application created 26 thumbnails, each measuring a mere 100 x 75 pixels. But attempting to create a 27th thumbnail produced an out-of-memory exception. When the exception occurred, Task Manager showed that the process's working set size had grown from 30 MB to nearly 1.5 GB! It seems crazy on the surface, because a full-color 100 x 75 image should only require about 30K of memory. But it makes a lot more sense when you realize that underlying each thumbnail is a gigantic BitmapImage that retains the full fidelity of the 3,648 x 2,736 original.

The obvious question is what do you do about it? Is there a way to efficiently create thumbnail images from streams of image bits in Silverlight? It's a question that pops up time and again in discussion forums and on message boards. And the short answer is yes, there is a way. But the answer probably isn't the one you expect.

Developers commonly attempt a solution along these lines:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Source = bi;

WriteableBitmap wb = new WriteableBitmap((int)cx, (int)cy);

ScaleTransform transform = new ScaleTransform();

transform.ScaleX = cx / bi.PixelWidth;

transform.ScaleY = cy / bi.PixelHeight;

wb.Render(image, transform);

wb.Invalidate();

Image thumbnail = new Image();

thumbnail.Width = cx;

thumbnail.Height = cy;

thumbnail.Source = wb;

return thumbnail;

}

The basic idea is that instead of creating a thumbnail by assigning a large BitmapImage to a small Image, you use WriteableBitmap.Render with a ScaleTransform to create a thumbnail, and then assign the WriteableBitmap to an Image. Meanwhile, the BitmapImage and the Image it was temporarily assigned to—the one passed to WriteableBitmap.Render—go out of scope and are eventually picked up by the garbage collector.

It works well in theory, but not so well in practice, thanks to an undocumented behavior of WriteableBitmap. In fact, when I plugged the revised CreateThumbnailImage method into my test harness, the application ran out of memory just as quickly as before.

The problem, it turns out, is that when you call WriteableBitmap.Render, WriteableBitmap apparently retains a reference to the XAML object passed in the first parameter. (I was stumped, too, until Jeffrey Richter and I did a little detective work and discovered what was happening under the hood. Jeffrey's my go-to guy for CLR issues, and I'm not sure I would have ever figured this out without him asking the right questions and suggesting solutions.) When CreateThumbnailImage returns an Image holding a reference to a WriteableBitmap, and the WriteableBitmap holds a reference to an Image, and the Image holds a reference to a BitmapImage, none of these objects gets garbage-collected. It seems that WriteableBitmap does nothing to solve the problem, especially given that there's no public method or property you can use to force the WriteableBitmap to release the reference.

But all is not lost. You can make a copy of the WriteableBitmap and assign it to the Image you return. And since you didn't call Render on the copy, it doesn't hold a reference to an Image that prevents the garbage collector from cleaning up the BitmapImage. Here is the fixed and final version of CreateThumbnailImage—this time, one that accomplishes what we set out to do:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Source = bi;

WriteableBitmap wb1 = new WriteableBitmap((int)cx, (int)cy);

ScaleTransform transform = new ScaleTransform();

transform.ScaleX = cx / bi.PixelWidth;

transform.ScaleY = cy / bi.PixelHeight;

wb1.Render(image, transform);

wb1.Invalidate();

WriteableBitmap wb2 = new WriteableBitmap((int)cx, (int)cy);

for (int i = 0; i < wb2.Pixels.Length; i++)

wb2.Pixels[i] = wb1.Pixels[i];

wb2.Invalidate();

Image thumbnail = new Image();

thumbnail.Width = cx;

thumbnail.Height = cy;

thumbnail.Source = wb2;

return thumbnail;

}

When I plugged this implementation into my test harness, it successfully created hundreds of thumbnails (and could have created hundreds, perhaps thousands, more) without significantly increasing the working set size—and without throwing out-of-memory exceptions.

The moral is that you should be very careful about how you use BitmapImage in Silverlight. Even one of them can swell the working set size dramatically, but a couple dozen of them wrapping digital photographs is more than most PCs can handle. With a little care, however, you can scale down the impact of BitmapImage so that memory consumption is proportional to the sizes of the images you're displaying rather than the sizes of the original, unreduced images. And that, in the end, is a handy arrow to have in your arsenal.

Silverlight 4's New Local File System Support

jprosise — Wed, 16 Dec 2009 19:56:00 GMT

In my last blog post, I wrote about Silverlight 4 applications that run outside the browser with elevated permissions and their ability to leverage COM automation servers on the host PC. Another privilege that applications with elevated permissions—also known as "trusted apps"—enjoy is the ability to access parts of the local file system without prompting the user with an OpenFileDialog or SaveFileDialog. This feature opens the door to types of applications that simply weren't possible with Silverlight 3.

File access is limited to certain locations on the hard disk: primarily the "My" folders such as My Documents, My Pictures, and My Music. But within those constraints, file system access works pretty much the same in Silverlight as it does in .NET. You generally begin by calling Environment.GetFolderPath to acquire a path to the folder you wish to access. The following code snippet enumerates the files in My Documents and stuffs the file names into a ListBox named FileList:

string path = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);

foreach (string file in Directory.EnumerateFiles(path))

{

FileList.Items.Add(file.Substring(file.LastIndexOf('\\') + 1));

}

Of course, you're not limited to enumerating files. You can open files, create files, and delete files, and you can do the same with directories. Plus, there's no limit on the amount of data you can write to the hard disk since the user okayed the elevated permissions when the application was installed.

To demonstrate Silverlight file access in action, I wrote the My Pictures Viewer pictured below. When started, it populates a TreeView control with all the folders and subfolders in your My Pictures directory. You can expand and collapse branches of the tree, and when you select a folder, the right half of the window is populated with thumbnail images of all the PNGs and JPGs in that directory. You can then click a thumbnail to see a close-up of the picture in a child window. Click the picture (or the X in the child window's upper right corner) to close the child window and continue photo browsing.

You can download the source code and try it for yourself. Run the application once in your browser and right-click it to install it as an out-of-browser application. Once the viewer is running outside the browser, you can begin browsing pictures.

The code to populate the TreeView with folder names looks like this:

if (Application.Current.HasElevatedPermissions)

{

string path = Environment.GetFolderPath(Environment.SpecialFolder.MyPictures);

foreach (string dir in Directory.EnumerateDirectories(path))

{

TreeViewItem item = new TreeViewItem();

item.Header = dir.Substring(dir.LastIndexOf('\\') + 1);

DirectoryTree.Items.Add(item);

ProcessFolder(dir, item.Items);

}

ProcessFolder is a recursive method that's implemented this way:

private void ProcessFolder(string path, ItemCollection items)

{

foreach (string dir in Directory.EnumerateDirectories(path))

{

TreeViewItem item = new TreeViewItem();

item.Header = dir.Substring(dir.LastIndexOf('\\') + 1);

items.Add(item);

ProcessFolder(dir, item.Items);

}

Perhaps the most interesting part of the source code is how it generates thumbnail images. It uses a BitmapImage to decode each image file. Then it assigns the BitmapImage to an Image object, uses WriteableBitmap.Render with a ScaleTransform to generate a thumbnail, and then, strangely enough, makes a copy of the WriteableBitmap in another WriteableBitmap. The second WriteableBitmap is the one that's ultimately assigned to an Image object to display the thumbnail on the screen.

At first glance, this may appear gratuitous. Why not just assign the BitmapImage created from the image file directly to the Image that displays the thumbnail on the screen? Furthermore, why go to the trouble of making a copy of the WriteableBitmap? The short answer is that I did it this way to avoid out-of-memory exceptions, which are all too common in Silverlight applications that display digital photos. In fact, I'm planning a follow-up blog post that covers this in detail. Stay tuned.

Silverlight 4's New COM Automation Support

jprosise — Mon, 14 Dec 2009 16:47:00 GMT

One of Silverlight 4's most compelling new features is support for out-of-browser applications with elevated permissions. An app running with elevated permissions can perform actions that a normal sandboxed application can not. For example, it can access the local file system, and on Windows boxes, it can interact with COM automation servers. This latter feature—also new to Silverlight 4—is the subject of this blog post.

Silverlight 4's ComAutomationFactory class provides an API for instantiating COM automation objects and for determining whether COM automation is available. (It's not available if the app is running without elevated permissions, or if it's running on a Macintosh.) And C# 4.0's new dynamic keyword provides a means for interacting with automation objects, which by definition are late-bound (meaning they expose features to clients using an IDispatch interface).

One practical example of what you can do with Silverlight's COM automation support is sending an e-mail message via Outlook. The following sample does just that:

dynamic outlook = ComAutomationFactory.CreateObject("Outlook.Application");

dynamic mail = outlook.CreateItem(0);

mail.Recipients.Add("webmaster@contoso.com");

mail.Subject = "Hello, Silverlight";

mail.Body = "This message was sent from Silverlight 4";

mail.Save();

mail.Send();

The code is exceedingly simple and it works just fine if Outlook is installed on the client and the user OKs the prompt from Outlook warning that an external application is attempting to use it. For added robustness, you should catch the System.Exception thrown from ComAutomationFactory.CreateObject if object creation fails. That's exactly what will happen if Outlook isn't installed on the host PC.

For fun, I wrote a downloadable demo that uses Microsoft's speech automation server to verbalize error messages. (I definitely wouldn't recommend using this in a production application because it is quite annoying, but it's just novel enough to get a few laughs from your friends.) Here's how the application looks when it's running:

If you click a button while the application is running inside the browser or outside the browser but without elevated permissions, the error message encapsulated in the ensuing exception is displayed in a message box. However, if you do the same with the application running with elevated permissions outside the browser, a friendly voice reads the error message out loud. Nothing calls attention to a null reference exception like a female voice informing you "Object reference not set to an instance of an object." For added fun, you could append "I'm sorry, Dave; I'm afraid I can't do that" to every error message.

When the application starts up, it attempts to instantiate the speech server and assign a reference to a local field:

if (ComAutomationFactory.IsAvailable)

{

try

{

_speech = ComAutomationFactory.CreateObject("Sapi.SpVoice");

}

catch (Exception) { }

}

Then, when an exception is thrown, it forwards the exception to a helper method named NotifyException, which verbalizes the error message if possible or displays it in a message box if not:

private void NotifyException(Exception ex)

{

if (_speech != null)

_speech.Speak(ex.Message);

else

MessageBox.Show(ex.Message);

}

If you install the application locally and OK its request for elevated permissions, you should hear (rather than see) the error messages. How's that for an error UI? :-)

Silverlight 4's New Commanding Support

jprosise — Tue, 01 Dec 2009 02:33:00 GMT

One of the exciting new features in the Silverlight 4 beta is a pair of properties added to the ButtonBase and Hyperlink classes named Command and CommandParameter. These properties represent the first real support in Silverlight for commanding, which is primarily beneficial to to Model-View-ViewModel (MVVM) applications. MVVM has long been popular among WPF developers and is rapidly gaining popularity with Silverlight developers. And now, thanks to commanding, Silverlight comes a little closer to supporting pure MVVM implementations without help from auxiliary frameworks such as Prism.

To demonstrate Silverlight 4's new commanding infrastructure, I took a sample that I originally wrote to show how to consume RSS in Silverlight. You type an RSS URL into a TextBox and click the "View" button. The app uses a WebClient to fetch the RSS feed, and then renders the feed items into a ListBox using data binding:

I then rewrote the app as an MVVM app and took advantage of commanding to move all the logic that used to appear in the code-behind to the view-model. You can download the source code to see how it works. Here are some of the highlights.

First, my model is implemented in the RssModel class. RssModel exposes a method named GetRssFeedAsync that the view-model can use to fetch a live RSS feed. It also implements a couple of events: an RssLoadComplete event that's fired following a successful RSS download, and an RssLoadError event that's fired if an RSS download fails. These methods and events are part of an interface named IRssProvider, which you could mock in a unit-testing scenario to provide RSS content from a local source rather than a network source.

Second, my view-model is implemented in a class named RssViewModel. Part of the intent of the view-model is to provide properties that the view can bind to to populate controls with data. To that end, RssViewModel exposes a string property named RssUri which can be bound to the TextBox in the view, and an ObservableCollection property named RssFeed that can be bound to the ListBox. It also implements a read-only ICommand property named GetRssFeed that returns an instance of a class named GetRssFeedCommand. This is where commanding enters the picture in Silverlight 4.

Open the code-behind file for the view (RssView.xaml.cs) and you'll see that it contains no code other than a constructor that calls InitializeComponent. In Silverlight 3, I would have had to include a handler for the button's Click command that calls into the view-model to fetch the RSS feed and stuff the RSS items into the RssFeed property. Thanks to the new commanding infrastructure in Silverlight 4, I was able to accomplish this declaratively. First, the view declares an instance of the view-model:

<UserControl.Resources>

<local:RssViewModel x:Key="RssViewModel" />

</UserControl.Resources>

Then it binds the view-model to the DataContext property of the Grid that contains the TextBox, ListBox, and Button:

The TextBox's Text property and the ListBox's ItemsSource property are bound to the view-model's RssUri and RssFeed properties:

More importantly, the Button is bound to the view-model this way:

Observe that the Button declaration doesn't contain a Click attribute; in other words, the Click event isn't bound to an event handler in the code-behind. Instead, when the button is clicked, it invokes the command exposed through the view-model's GetRssFeed property. That command is implemented this way:

public class GetRssFeedCommand : ICommand

{

private IRssProvider _model;

private ObservableCollection<SyndicationItem> _feed;

public GetRssFeedCommand(ObservableCollection<SyndicationItem> feed, IRssProvider model)

{

_feed = feed;

_model = model;

}

public event EventHandler CanExecuteChanged;

public bool CanExecute(object parameter)

{

return true;

}

public void Execute(object parameter)

{

_model.RssLoadComplete += new EventHandler<RssEventArgs>(OnRssLoadComplete);

_model.GetRssFeedAsync(new Uri((string)parameter, UriKind.Absolute));

}

void OnRssLoadComplete(object sender, RssEventArgs e)

{

if (_feed != null) // Just to be sure

{

_feed.Clear();

using (XmlReader reader = XmlReader.Create(e.Result))

{

SyndicationFeed feed = SyndicationFeed.Load(reader);

foreach (SyndicationItem item in feed.Items)

_feed.Add(item);

}

At run-time, invoking the command causes its Execute method to be called, and the command responds by using the model to fetch the RSS feed and parsing the feed items into the view-model's RssFeed property. Thanks to the data binding between that property and the ListBox, and because RssFeed is an ObservableCollection, the items promptly appear in the ListBox.

The binding between the Button and the view-model's GetRssFeed property is possible because of the Command property added to the Button class (actually, to ButtonBase) in Silverlight 4. In addition, Button now contains a CommandParameter property that can be used to pass a parameter to the command. In this example, CommandParameter is bound to the view-model's RssUri property, which ensures that the URL typed by the user is available to the command when the command is invoked.

The upshot of all this is that Command and CommandParameter enabled me to build a pure MVVM implementation that wasn't possible in Silverlight 3 without outside help. It's not the final word in commanding—after all, Silverlight still lacks commanding support in other controls such as ListBox—but it's a step in the right direction. And it's indicative of the fact that the Silverlight team is listening to developers, because commanding, along with printing and support for webcams and other devices, is one of the features that developers lobbied for the most.

Silverlight 4's New Drag-and-Drop Support

jprosise — Thu, 26 Nov 2009 16:26:00 GMT

Another new feature of Silverlight 4 that will enable developers to build richer UIs is drag-and-drop file support. In Silverlight 3, you had to pop up an OpenFileDialog to allow the user to select files from the local file system and make them available to a Silverlight application. In Silverlight 4, OpenFileDialog still works, but there is an alternative: let the user drag files from the operating system shell and drop them into a Silverlight application. The app can then consume the files in much the same way that it consumes files offered through OpenFileDialog.

To demonstrate the mechanics of Silverlight drop targeting, I built a sample that lets you open image files using drag-and-drop. Here's what the app looked like after I grabbed a bunch of JPEGs from My Pictures and dropped them into the running application:

At startup, the application registers a handler for the new Drop event attached to the UIElement class, making the LayoutRoot Grid a drop target:

// Register a handler for Drop events

LayoutRoot.Drop += new DragEventHandler(LayoutRoot_Drop);

When one or more files are dropped into the Grid, LayoutRoot_Drop inserts the FileInfo objects representing the dropped files into a System.Collections.Generic.Queue:

// Queue the FileInfo objects representing dropped files

if (e.Data != null)

{

FileInfo[] files = e.Data.GetData(DataFormats.FileDrop) as FileInfo[];

foreach (FileInfo fi in files)

{

_files.Enqueue(fi);

}

Later, a CompositionTarget.Rendering event handler dequeues the FileInfo objects and processes them one at a time (one FileInfo object per CompositionTarget.Rendering event), turning them into XAML Image objects with Borders around them:

if (_files.Count != 0)

{

// Create a photo

FileInfo fi = _files.Dequeue();

CreatePhoto(fi);

}

The reason for using CompositionTarget.Rendering is that images have to be decoded and created on the application's UI thread. By processing one FileInfo object and returning, the event handler hands control back to Silverlight so the rendering engine can render the photo that was just added to the scene.

To enable applications to support drag-and-drop, Silverlight 4 adds four new events named DragEnter, DragOver, Drop, and DragLeave to the UIElement class. Therefore, any visual element can be a drop target. In non-Silverlight applications, you can use the IDataObject passed to these event handlers to determine what type of data is being offered. In Silverlight, however, you can only query the IDataObject in handlers for Drop events. Still, you could use the other events to perform drop-target highlighting or other UI-related chores when a cursor carrying a payload enters a drop target.

Another facet of the drag-and-drop story is the new UIElement.AllowDrop property. In order for an object to accept drops, this property must be set to true. That's why my sample application declares the LayoutRoot grid this way:

You can download the source code and try it for yourself. Have fun dropping files!

Silverlight 4's New Clipboard Support

jprosise — Wed, 25 Nov 2009 15:58:00 GMT

Among the many new features coming in Silverlight 4 is clipboard support. A new class named System.Windows.Clipboard provides three static methods for accessing the system clipboard:

GetText, which retrieves text from the clipboard
SetText, which places text on the clipboard
ContainsText, which indicates whether the clipboard currently contains text

In the Silverlight 4 beta, only Unicode text can be retrieved from the clipboard or added to it. Microsoft hasn't said whether the final release will support additional clipboard formats, but one can always hope.

To demonstrate, I built a sample app that features a Paste button for pasting text from the clipboard into a TextBlock. It uses a DispatcherTimer to enable or disable the Paste button once a second based on the clipboard's contents (specifically, whether or not the clipboard currently contains Unicode text). Here's the XAML:

<Grid.Background>

</LinearGradientBrush>

</Grid.Background>

<Button x:Name="PasteButton" Width="100" Height="50" Margin="32"

Content="Paste" IsEnabled="False" Click="Button_Click" />

<TextBlock x:Name="Output" Foreground="White" FontSize="20"

TextWrapping="Wrap" HorizontalAlignment="Center"

VerticalAlignment="Center" Margin="32,0,32,32" />

</StackPanel>

</Grid>

And here's the code-behind:

public partial class MainPage : UserControl

{

private DispatcherTimer _timer;

public MainPage()

{

InitializeComponent();

_timer = new DispatcherTimer();

_timer.Interval = new TimeSpan(0, 0, 1);

_timer.Tick += new EventHandler(_timer_Tick);

_timer.Start();

}

void _timer_Tick(object sender, EventArgs e)

{

PasteButton.IsEnabled = Clipboard.ContainsText();

}

private void Button_Click(object sender, RoutedEventArgs e)

{

try

{

Output.Text = Clipboard.GetText();

}

catch (SecurityException ex)

{

MessageBox.Show(ex.Message);

}

If the application is running in the browser or if it's running outside the browser without elevated permissions, clicking the Paste button produces the following confirmation dialog:

If the user answers yes, the application is permitted to access the clipboard. Here's the result when I pasted in the text of the Gettysburg Address:

If the user denies the application clipboard access, then GetText produces a SecurityException. That's why I wrapped the call to GetText in a try/catch block—just in case. On a positive note, if the user answers yes when asked if the application can access the clipboard, the answer is cached for the duration of the session and the prompt isn't displayed again.

Silverlight 4's Improved Element Data Binding

jprosise — Wed, 25 Nov 2009 15:03:00 GMT

Earlier this year, I wrote about Silverlight 3's new element data binding feature, which enables XAML elements to be bound together declaratively. I also bemoaned the fact that the target of an element-to-element data binding had to be a Framework-element derivative. Good news! Silverlight 4 fixes this by extending element data binding to DependencyObject derivatives.

My Silverlight 3 element data binding sample was built from the following XAML:

<Border.Projection>

</Border.Projection>

<user:PenguinUserControl />

</Border>

<Slider Minimum="0" Maximum="360"

Value="{Binding RotationX, ElementName=Projector, Mode=TwoWay}"

Width="400" VerticalAlignment="Top" Margin="0,20,0,0" />

<Slider Minimum="0" Maximum="360"

Value="{Binding RotationY, ElementName=Projector, Mode=TwoWay}"

Width="400" VerticalAlignment="Top" Margin="0,20,0,0" />

<Slider Minimum="0" Maximum="360"

Value="{Binding RotationZ, ElementName=Projector, Mode=TwoWay}"

Width="400" VerticalAlignment="Top" Margin="0,20,0,0" />

</StackPanel>

</Grid>

The result was a penguin that could be rotated about the X, Y, and Z axes using Sliders:

When I wrote this demo, I wanted to attach the {Binding} expressions to the PlaneProjection, not the Slider controls. But Silverlight 3 didn't allow this because PlaneProjection isn't a FrameworkElement. My recourse was to apply the bindings to the Sliders themselves and to use 2-way bindings to sync the Sliders' Value properties with the PlaneProjection's RotationX, RotationY, and RotationZ properties.

Such shenanigans are no longer necessary in Silverlight 4, which supports the following syntax:

<user:PenguinUserControl>

<user:PenguinUserControl.Projection>

<PlaneProjection

RotationX="{Binding Value, ElementName=SliderX}"

RotationY="{Binding Value, ElementName=SliderY}"

RotationZ="{Binding Value, ElementName=SliderZ}" />

</user:PenguinUserControl.Projection>

</user:PenguinUserControl>

<Slider x:Name="SliderX" Minimum="0" Maximum="360" Width="400"

VerticalAlignment="Top" Margin="0,20,0,0" />

<Slider x:Name="SliderY" Minimum="0" Maximum="360" Width="400"

VerticalAlignment="Top" Margin="0,20,0,0" />

<Slider x:Name="SliderZ" Minimum="0" Maximum="360" Width="400"

VerticalAlignment="Top" Margin="0,20,0,0" />

</StackPanel>

</Grid>

Also note that you can now apply a PlaneProjection directly to a user control. Silverlight 3 didn't support this, which explains why in the Silverlight 3 version of this demo, I enclosed the user control in a Border and applied the PlaneProjection to the Border. This is yet another new feature of Silverlight 4 that further narrows the gap between Silverlight and WPF.

Silverlight 4's New Implicit Styles

jprosise — Wed, 25 Nov 2009 14:25:00 GMT

Silverlight 4 introduces a boatload of big-ticket features such as printing support, webcam and microphone support, and support for elevated trust in out-of-browser applications. It's also chock full of minor improvements that fly lower under the radar. One of my favorite features in this category is support for implicit styles.

In Silverlight 3, there was no built-in way to define a style and have it automatically applied to all controls of a specified type. Sure, you could use the Silverlight Toolkit's implicit style manager to apply default styles, but the fact remained that the run-time itself lacked support for the same.

In Silverlight 4, you can define an implicit style by omitting the x:Key attribute from the <Style> element. Unless otherwise specified, that style will be applied to all elements of the type specified by the style's TargetType. Here's an example. The following XAML declares three buttons and styles them with an implicit style that rotates them 15 degrees:

<UserControl.Resources>

<Setter.Value>

</Setter.Value>

</Setter>

</Style>

</UserControl.Resources>

</StackPanel>

</Grid>

Here's the result:

Of course, you might want to use implicit styles but exclude certain controls from being implicitly styled. You can do that by setting a control's Style property to x:Null:

<UserControl.Resources>

<Setter.Value>

</Setter.Value>

</Setter>

</Style>

</UserControl.Resources>

</StackPanel>

</Grid>

And here is the resulting UI:

Implicit styles are a welcome addition to Silverlight 4, and I'm confident that developers will find this feature to be as useful in Silverlight as they have already found it to be in WPF.

Silverlight 3's New Application Extension Services

jprosise — Fri, 06 Nov 2009 14:04:00 GMT

Another feature of Silverlight 3 that has flown under the radar since the product's release is application extension services, or application services for short. Application services are client-side services that start when the application starts and end when the application ends. In other words, their lifetime parallels that of the application itself. An application service is an excellent deployment vehicle for features that in Silverlight 2 might have been added to the Application-derived class in App.xaml.cs.

Writing an application service is a simple matter of building a class that implements Silverlight's IApplicationService interface. That interface has just two methods: StartService and StopService, which are called when the service starts and when it ends. In practice, StartService is called immediately before the Application.Startup event fires, and StopService is called right after the Application.Exit event fires. A skeletal service implementation appears below. Note the static property named Current, which provides a simple means for application code to acquire a reference to a running service instance:

public class SimpleService : IApplicationService

{

private static SimpleService _current = null;

public static SimpleService Current

{

get { return _current; }

}

// TODO: Implement other class members here

public void StartService(ApplicationServiceContext context)

{

_current = this;

}

public void StopService()

{

_current = null;

}

Although not shown in the example above, a service can optionally implement the IApplicationLifetimeAware interface, too. This interface adds four methods named Starting, Started, Exiting, and Exited. Calls to these methods bracket calls to StartService and StopService and provide an application service with additional opportunities to perform any necessary initialization or cleanup chores.

Application services are loaded by declaring instances of them in App.xaml:

<Application

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

x:Class="SimpleServiceDemo.App"

xmlns:local="clr-namespace:SimpleServiceDemo"

<Application.Resources>

</Application.Resources>

<Application.ApplicationLifetimeObjects>

<local:SimpleService />

</Application.ApplicationLifetimeObjects>

</Application>

ApplicationLifetimeObjects is a new property added to the Application class in Silverlight 3. You can use it to register application services as shown above, and also to enumerate loaded services at run-time.

So, the big question: why would you ever write one of these things? To demonstrate, I built an application service named AssemblyLoaderService that provides a useful service to Silverlight applications that rely on external assemblies: asynchronous assembly loading. Rather than swell the size of your XAP file by packing it with extra assemblies, you can register those assemblies with the assembly loader service when the application starts up and allow the service to download them in the background and load them into the app domain. It's an easy way to deploy applications that utilize multiple assemblies without increasing the size of the XAP and delaying the startup of the entire application. Done properly, it also allows you to avoid jumping through some of the hoops I described in an earlier blog post on dynamic assembly loading in Silverlight.

You can download the source code for AssemblyLoaderService (and a sample app that uses it) from Wintellect's Web site. When you run the application, you'll initially see a blank page. After a short time (very short since you're running against a local Web server), a button will appear. Clicking the button removes the button from the page and replaces it with a dynamically created Calendar control.

It's what happens on the inside that's interesting. The Calendar class lives in System.Windows.Controls.dll, which isn't part of the core Silverlight run-time. To create a Calendar control, you must include a reference to System.Windows.Controls.dll in your project. Normally, that increases the size of your XAP file. Here it doesn't, because after adding the assembly reference to the project, I changed the assembly's Copy Local setting from true to false. This satisfies the compiler but prevents the assembly from being packaged in the XAP file.

The following statements in MainPage.xaml.cs initiate an asynchronous download of System.Windows.Controls.dll from the server's ClientBin folder:

AssemblyLoaderService als = AssemblyLoaderService.Current;

if (als != null) // Just to be sure

{

als.AssemblyLoaded +=

new EventHandler<AssemblyLoadedEventArgs>(OnAssemblyLoaded);

als.AssemblyLoadedError +=

new EventHandler<AssemblyLoadedErrorEventArgs>(OnAssemblyLoadedError);

als.LoadAssemblyAsync(new Uri("System.Windows.Controls.dll", UriKind.Relative));

}

Before calling the service's LoadAssemblyAsync method to start the download, MainPage registers handlers for the service's AssemblyLoaded and AssemblyLoadedError events, which notify interested parties when an assembly is successfully loaded, or when an error prevents an assembly from being loaded. MainPage's AssemblyLoaded event handler displays the "Create Calendar Control" button to the user, so there's no chance that the application will attempt to create a Calendar control before the required assembly has been loaded into the app domain.

The service is implemented in the AssemblyLoaderService class. Look through the source code and you'll see that it sometimes uses a DispatcherSynchronizationContext to marshal to the application's UI thread. That's because AssemblyPart.Load throws an exception if called from a background thread, and also because I wanted all events fired by the service to execute on the UI thread. I'll describe all this and more next week in Berlin when I do my "Biggest Little-Known Features in Silverlight" talk at TechEd, so if you're attending the conference, please come by and join the fun!

Silverlight 3's New {RelativeSource} Markup Extension

jprosise — Fri, 06 Nov 2009 03:00:00 GMT

One of the more obscure features introduced in Silverlight 3 is the {RelativeSource} markup extension. It's poorer than its counterpart in WPF because the Silverlight version supports only two modes: Self and TemplatedParent. There are precious few examples out there demonstrating why you'd ever need {RelativeSource} in Silverlight. Here's one example.

Suppose you're building a custom control named SuperSlider that wraps (and presumably adds functionality to) the built-in Slider control, and that the default control template looks something like this:

<Setter.Value>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

It looks reasonable, but try setting SuperSlider's Value property and you'll find that the thumb doesn't move. In addition, if the user slides the Slider control's thumb, SuperSlider's Value property doesn't change. Why? Because a TemplateBinding is inherently a 1-way binding. You need a 2-way binding to forge a robust connection between SuperSlider's Value property and the Slider's Value property.

In Silverlight 2, you had to write code to overcome this. In Silverlight 3, you can do it declaratively by combining {Binding} with {RelativeSource}:

<Setter.Value>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

That's one use for {RelativeSource} in Silverlight: creating 2-way template bindings. There are others, and for examples you need look no further than the default control templates for ListBox and a handful of other controls included in Silverlight 3.

Implementing CoverFlow in Silverlight 3

jprosise — Thu, 05 Nov 2009 15:12:00 GMT

Apple's CoverFlow interface has become popular for presenting collections of items in a highly browseable format, especially on mobile devices where real estate is limited. Thanks to the PlaneProjection class introduced in Silverlight 3, CoverFlow interfaces are now possible in Silverlight, too.

I recently set out to build a control that encapsulates all the features needed to build CoverFlow interfaces in Silverlight. But then a funny thing happened: I found out that someone else had already done it and published the code on CodePlex. I don't often use code written by others in the samples that I create, but I was so impressed with Darick's open-source CoverFlow control that I made an exception. It includes some nice touches from a UI perspective, including the use of animation easing to decelerate as you come to a stop after flipping through the items, as well as support for data binding, data templates, and more. (The author chose wisely when he decided to derive from ItemsControl!) But more importantly, it works really well, and flipping through even large numbers of items is smooth as glass. That's no small feat given that applying a PlaneProjection to an item in Silverlight 3 prevents that item from being rendered by the GPU.

I built a demo around the control that lets you flip through my collection of Fantastic Four comic books:

You can run the demo from Wintellect's Web site, or you can download the source code and run it locally. There's not much for me to say about the source code since the CoverFlow control does most of the work. Just for fun, I did add gesture support to the demo so you can flip backward and forward by dragging the mouse left and right. You can uncheck the "Enable gestures" box to disable that feature.