| Comments

A developer asked me this question and while a simple answer, I thought it would be a good quick tip to share for those who may be in similar situations.

The scenario is the classic master-details scenario where perhaps you have a grid of data and when a user selects the row, the details are enabled in a form (or perhaps the child of the element) for editing.  Maybe something like this:

Master-details Typical view

See you can see the row clearly selected (note: this is using the default DataGrid styling).  But watch what happens when you go to the form to edit:

Focus change on selected row

Notice the focus now on the TextBox in the form, and the row, while still ‘selected’ is much more subtle in which row is selected.  The uninformed eye might miss which one.  For some scenarios this might be important.  Some might even think the row isn’t selected anymore since the visual state changed.

In fact it still *IS* selected and the only thing that changed *IS* the visual state…literally.  Since Silverlight has the concept of the VisualStateManager, that is what we are seeing in action here.  So you want to change that to make your desired UI as expected…having the row retain it’s selected look even when the user is editing.  This is simple.

Using Expression Blend, you can select the DataGrid element and then choose Edit Additional Templates to find the RowStyle template to edit a copy of:

Expression Blend edit template

Once you have this, click the States tab in the tool and you’ll see the various visual states that a DataGridRow can have.  Notice the NormalSelected and UnfocusedSelected states:

Visual States for DataGridRow

You would modify the Fill.Color property of the UnfocusedSelected state to accomplish the desired change.  In this example, I just used the same color as the default grid for illustration.  The end result is what the user may be expecting more.  Notice the focus is on the TextBox in the form still, but the row still has a prominent selected color view:

Fixed focus visual UI

A simple edit, but a helpful UI change to give your users more indication of what they are doing.  Of course I’m just using the default styles of the DataGrid here, but you could use your own styles as well.  Hope this helps!

Here is my style XAML as I completed the task above: StaySelectedStyle.txt

| Comments

I previously wrote about DataGrid grouping using the declarative model of adding GroupDescriptors.  Unfortunately that feature (the declarative part) never made it to the release of Silverlight 3.  It was pointed out to me that I should update that post and it has been on my //TODO list for a while.  Here’s an update…

First, I’m still using a sample data class of Person as my test data:

   1: using System.Collections.Generic;
   3: namespace DataGridGroupingUpdated
   4: {
   5:     public class Person
   6:     {
   7:         public string FirstName { get; set; }
   8:         public string LastName { get; set; }
   9:         public string Gender { get; set; }
  10:         public string AgeGroup { get; set; }
  11:     }
  13:     public class People
  14:     {
  15:         public static List<Person> GetPeople()
  16:         {
  17:             List<Person> peeps = new List<Person>();
  18:             peeps.Add(new Person() { FirstName = "Tim", LastName = "Heuer", Gender = "M", AgeGroup = "Adult" });
  19:             peeps.Add(new Person() { FirstName = "Lisa", LastName = "Heuer", Gender = "F", AgeGroup = "Adult" });
  20:             peeps.Add(new Person() { FirstName = "Zoe", LastName = "Heuer", Gender = "F", AgeGroup = "Kid" });
  21:             peeps.Add(new Person() { FirstName = "Zane", LastName = "Heuer", Gender = "M", AgeGroup = "Kid" });
  22:             return peeps;
  23:         }
  24:     }
  25: }

Then my XAML is a simple DataGrid (make sure to add assembly references to your project to System.Windows.Controls.Data):

   1: <UserControl x:Class="DataGridGroupingUpdated.MainPage"
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
   5:     xmlns:datacontrols="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
   6:     mc:Ignorable="d" d:DesignWidth="640" d:DesignHeight="480">
   7:     <Grid x:Name="LayoutRoot">
   8:         <StackPanel>
   9:             <StackPanel Orientation="Horizontal">
  10:                 <TextBlock Text="Group:" Margin="0,0,10,0" />
  11:                 <ComboBox x:Name="GroupNames" SelectionChanged="GroupNames_SelectionChanged">
  12:                     <ComboBox.Items>
  13:                         <ComboBoxItem Content="AgeGroup" IsSelected="True" />
  14:                         <ComboBoxItem Content="Gender" />
  15:                     </ComboBox.Items>
  16:                 </ComboBox>
  17:             </StackPanel>
  18:             <datacontrols:DataGrid x:Name="PeopleList" />
  19:         </StackPanel>
  20:     </Grid>
  21: </UserControl>

Notice the xmlns:datacontrols declaration at the top.

Now since we can’t do the grouping declaratively as in my previous sample with Silverlight 3 beta, here’s how we could do it.  In Silverlight 3 you have access to PagedCollectionView (add a reference to System.Windows.Data to get it).  This is a view that enables you to add sort and group descriptors.  In my initial loading code I instantiate a new PagedCollectionView passing in my List<Person> as the enumerable type.  I then set a default grouping on it.

   1: PagedCollectionView pcv = null;
   3: public MainPage()
   4: {
   5:     InitializeComponent();
   6:     Loaded += new RoutedEventHandler(MainPage_Loaded);
   7: }
   9: void MainPage_Loaded(object sender, RoutedEventArgs e)
  10: {
  11:     pcv = new PagedCollectionView(People.GetPeople());
  12:     pcv.GroupDescriptions.Add(new PropertyGroupDescription("AgeGroup"));
  14:     PeopleList.ItemsSource = pcv;
  15: }

Then I can wire up a quick and dirty (just for demonstration purposes) ComboBox to show changing the grouping (or perhaps adding another one if you’d like):

   1: private void GroupNames_SelectionChanged(object sender, SelectionChangedEventArgs e)
   2: {
   3:     if (pcv != null)
   4:     {
   5:         // comment this next line out to see
   6:         // adding additional groupings.
   7:         pcv.GroupDescriptions.Clear();
   8:         ComboBoxItem itm = (ComboBoxItem)GroupNames.SelectedItem;
   9:         pcv.GroupDescriptions.Add(new PropertyGroupDescription(itm.Content.ToString()));
  10:     }
  11: }

You see we are just changing the PagedCollectionView and not the DataGrid.  The binding that exists between them already understands what to do – so we just have to change the data source, not the control displaying the source.  Put them all together and the running application shows the grouping:

DataGrid grouping sample image

Hopefully this helps clarify the change from SL3 beta and apologies for the delay in updating what is a common sample request.  Who knows, maybe in future versions the declarative model will come back :-).  Here’s the code for the above if you’d like to see it: DataGridGroupingUpdated.zip

| Comments

This is part 2 in a series on getting started with Silverlight.  To view the index to the series click hereYou can download the completed project files for this sample application in C# or Visual Basic.

Understanding layout management in XAML applications is an important aspect in being successful in Silverlight development.  For most coming from the web world, this will be one of the bigger challenges if you are not a CSS wizard.

Understanding Layout Options

Silverlight provides a flexible system for laying out UI elements on a surface.  There are layout models to support both a dynamic and absolute layout style.  There are several layout controls provided but the most commonly used will be:

  • Canvas
  • StackPanel
  • Grid

Let’s take a look at each of these using elements placed within them to see how they work.  We’ll use a simple Button element to demonstrate the purpose.  We’re using the same project we started with in step 1 and will show these on the Home.xaml page for simplicity (this is throw away code so just pick somewhere to play around for now).


The Canvas is the most basic layout and would be used for positioning elements in an absolute manner using coordinates.  You position elements in the Canvas using Attached Properties. Attached properties allow the parent container (in this case Canvas) to extend the property of the controls within it (in our example Button).  We can position several buttons on a Canvas like this:

   1: <Canvas>
   2:     <Button Canvas.Top="50" Canvas.Left="50" Content="Button 1" FontSize="18" Width="150" Height="45" />
   3:     <Button Canvas.Top="150" Canvas.Left="20" Content="Button 2" FontSize="18" Width="150" Height="45" />
   4:     <Button Canvas.Top="70" Canvas.Left="80" Canvas.ZIndex="99" Content="Button 3" FontSize="18" Width="150" Height="45" />
   5: </Canvas>

and when rendered it would show something like this:

Canvas layout

As you can see, this is the absolute positioning approach to layout.  Notice in the code I can also specify an attached property for ZIndex which is why one Button is overlapping the other in this example.  This might be helpful in game development or high physics situations where the calculations are very specific.  Canvas is useful when things don’t move around much or you are pretty in control of the sizing of the application.  Otherwise, Canvas can sometimes be difficult to leverage in favor of things like StackPanel or Grid.


A StackPanel is a layout control which stacks the elements either vertically or horizontally (vertical by default).  Using the sample with 3 Buttons and this code:

   1: <StackPanel>
   2:     <Button Margin="10" Content="Button 1" FontSize="18" Width="150" Height="45" />
   3:     <Button Margin="10" Content="Button 2" FontSize="18" Width="150" Height="45" />
   4:     <Button Margin="10" Content="Button 3" FontSize="18" Width="150" Height="45" />
   5: </StackPanel>

the layout rendered would be:

StackPanel vertical

or if we change the default Orientation attribute to horizontal using this code (notice only difference is Orientation attribute on StackPanel):

   1: <StackPanel Orientation="Horizontal">
   2:     <Button Margin="10" Content="Button 1" FontSize="18" Width="150" Height="45" />
   3:     <Button Margin="10" Content="Button 2" FontSize="18" Width="150" Height="45" />
   4:     <Button Margin="10" Content="Button 3" FontSize="18" Width="150" Height="45" />
   5: </StackPanel>

it would render like:

StackPanel horizontal

StackPanel provides a simple way to layout elements on top of each other or alongside each other without much challenge of worrying about the positioning of the elements within this container.


Grid is going to usually be the most flexible layout for most scenarios (notice I said most, not all).  It is exactly what it sounds like, a Grid structure using rows and columns.  Unlike what web developers may be used to with the <table> element where the content is within the <tr>,<td> tags, the XAML Grid is different.  You define the overall structure of the Grid and then use attached properties to tell the elements where to place themselves.

Consider this code (notice I’m explicitly showing grid lines but that isn’t something you’d normally do generally…just showing here for better visualization):

   1: <Grid ShowGridLines="True">
   2:     <Grid.RowDefinitions>
   3:         <RowDefinition Height="60" />
   4:         <RowDefinition Height="60" />
   5:         <RowDefinition Height="60" />
   6:     </Grid.RowDefinitions>   
   8:     <Grid.ColumnDefinitions>
   9:         <ColumnDefinition Width="175" />
  10:         <ColumnDefinition Width="175" />
  11:         <ColumnDefinition Width="175" />
  12:     </Grid.ColumnDefinitions>
  14:     <Button Grid.Column="0" Grid.Row="0" Content="Button 1" FontSize="18" Width="150" Height="45" />
  15:     <Button Grid.Column="2" Grid.Row="0" Margin="10" Content="Button 2" FontSize="18" Width="150" Height="45" />
  16:     <Button Grid.Column="1" Grid.Row="2" Margin="10" Content="Button 3" FontSize="18" Width="150" Height="45" />
  17: </Grid>

We are defining the Grid to have 3 columns and 3 rows with specific width and heights.  Notice then in the Button elements we are positioning them in specific places within the Grid using the attached properties.  The resulting rendering looks like this:

Notice how the attached properties on the Button (Grid.Column, Grid.Row) tell the element where to position itself within the container.  Working with layouts is where Expression Blend can be extremely helpful.  Notice how in Blend you can use the guides to specify the column/row definitions visually and it will generate the XAML for you:

Grid in Blend

The arrows show you the guides as well as a visual indicator if the row/column are a fixed size (the lock).  We’ll use a combination of layout controls in our application.  In fact, the default template we chose makes use of all the different types of layout controls already for our basic shell for our application.

Building our Twitter Application

Now we can start building out our application.  In general, this is the mockup that we’ll be going after:

Twitter app mockup

Notice that we’ll have a place for the user to enter a search term, and the results will display in some list layout.  We’ll also have navigation areas to go to different views such as previous search term history and possibly some statistics.

Luckily the navigation template we chose already gives us some heavy lifting of our overall layout.  In MainPage.xaml I’m going to make a few changes.  On about line 29 in MainPage.xaml, I’m removing the application logo, and then changing the ApplicationnameTextBlock below it to “Twitter Search Monitor” for my application.

We’ll get back to navigation in a minute, but let’s recreate our Views.  In the project structure in the Views folder, create a new Page by right-clicking in Visual Studio and choosing to create a new Silverlight Page and name it Search.xaml:

Add Silverlight Page dialog

Now you should have a blank XAML page with a default Grid layout.  This is where we’ll create the search screen seen above.  We get the header information from our MainPage.xaml because we are using a Frame element to host our navigation.

Silverlight Navigation Framework

At this point let’s take a tangent and understand the Silverlight navigation framework.  If you recall we started using the navigation application template.  The default template gave us MainPage.xaml and some views of Home, About.  The navigation framework is fundamentally made up of 3 parts: UriMapper, Frame and Page. 


I like to think of the UriMapper element as a routing engine of sorts.  It is not required by any means but I think obfuscates and simplifies your navigation endpoint.  Instead of exposing the literal /Views/Home.xaml URI endpoint, you can map that to a simpler “/Home” endpoint that is more readable and doesn’t give away and technical configuration…and can change later to map to something else.  You can see the UriMapper as an element of the Frame in MainPage.xaml:

   1: <navigation:Frame x:Name="ContentFrame" Style="{StaticResource ContentFrameStyle}" 
   2:                 Source="/Home" Navigated="ContentFrame_Navigated" 
   3:                 NavigationFailed="ContentFrame_NavigationFailed">
   4: <navigation:Frame.UriMapper>
   5:   <uriMapper:UriMapper>
   6:     <uriMapper:UriMapping Uri="" MappedUri="/Views/Home.xaml"/>
   7:     <uriMapper:UriMapping Uri="/{pageName}" MappedUri="/Views/{pageName}.xaml"/>
   8:   </uriMapper:UriMapper>
   9: </navigation:Frame.UriMapper>
  10: </navigation:Frame>

Now this UriMapper is in XAML like above, but it could also have been a resource and if done that way then you would add it to the Frame element like this (assuming the resource was UriMapperRoutes):


We’ll stick to keeping what the template has provided us though at this time.


If you are an ASP.NET developer, you can think of the Frame element as like the ContentPlaceholder control.  The Frame is the area defined as the area that can be navigated.  You would specify a default view but then any navigation can occur within that area which we will see later.  Looking at the code above, you can see that the default view, the Source attribute of the Frame, is the “/Home” route for our application.


The final fundamental area of navigation is the Page element, which we just created in our last step.  These are basically the content areas that are displayed in the Frame element.  They are very similar to the basic UserControl element that you might normally add (what MainPage is), but are special in that they can interact with navigation.  We will consider our Views in our application as our Page elements.

You can learn more about navigation specifically in this video walk-through:

It’s fairly simple to understand once you dig around in it and can be powerful to use.  This framework is what allows deep-linking into Silverlight applications to exist.

Creating the UI layout for our search view

Let’s finish creating the UI in our Search.xaml page we just created.  At this point you may be wondering what all the {StaticResource XXXXXXXX} elements are in the XAML.  We’ll get to that in the styling/templating section in step 5, so try not to let it bother you for now.

Looking at our mockup, we are going to need a text input area, button and data display grid.  Let’s start laying that out using Blend in our Search.xaml page.  To do this, from Visual Studio, right-click on the Search.xaml page and choose Edit in Expression Blend:

Open in Blend dialog

Since Blend and Visual Studio share the same project structures you will be able to open the file at the same time to do the visual editing of the XAML before we start coding away.

While in blend we’ll layout our Grid to have 2 rows, one for the search input/button and the second for the results view.  In the top row we’ll drag a StackPanel in there and add a TextBox and Button into the StackPanel, setting it for Orientation=Horizontal.

The next thing we’ll do is add a DataGrid to show our data.  Since DataGrid is not a core control, it is in the SDK libraries and we’ll need to add a reference to it.  You can do this in various ways.  Blend will actually do this automatically for you.  In the toolbox pallette for Blend, click the double arrow and search for DataGrid:

Add DataGrid

Once you see it, select it and drag it into the second row.  This automatically added the reference to the System.Windows.Controls.Data.dll for you and changed the markup in the XAML:

   1: <navigation:Page 
   2:            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   4:            xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
   5:            xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
   6:            mc:Ignorable="d"
   7:            xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
   8:            xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data" x:Class="TwitterSearchMonitor.Views.Search"
   9:            d:DesignWidth="640" d:DesignHeight="480"
  10:            Title="Twitter Search Page">
  11:     <Grid x:Name="LayoutRoot">
  12:         <Grid.RowDefinitions>
  13:             <RowDefinition Height="32"/>
  14:             <RowDefinition/>
  15:         </Grid.RowDefinitions>
  16:         <StackPanel HorizontalAlignment="Left" Margin="0,-32,0,0" VerticalAlignment="Top" Grid.Row="1" Orientation="Horizontal">
  17:             <TextBox x:Name="SearchTerm" FontSize="14.667" Margin="0,0,10,0" Width="275" TextWrapping="Wrap"/>
  18:             <Button x:Name="SearchButton" Width="75" Content="SEARCH"/>
  19:         </StackPanel>
  20:         <data:DataGrid x:Name="SearchResults" Margin="0,8,0,0" Grid.Row="1"/>
  21:     </Grid>
  22: </navigation:Page>

Notice the xmlns:data in the top.  This is how, after adding a reference to the assembly, you add non-core controls to the XAML.  Then to use them you’ll see the data:DataGrid element in the Grid.  Your XAML now should look a bit like mine and visually it looks like this:

Final initial layout

Notice in the XAML that I gave x:Name’s to my TextBox (SearchTerm), Button (SearchButton) and DataGrid (SearchResults).  This will help us later easily program against these elements.

Now if you go back to Visual Studio you may see a prompt to reload the project.  This is because Blend altered the project file by adding a reference to the DataGrid control.  You can go ahead and reload it.  This shows how integrated the tools are at the project file level.  Now we can start coding again using VS.

Changing our UriMapper to default to Search.xaml

Now that we just created the Search page (which is essentially our home page of the application), let’s make a few changes to the navigation framework.  In MainPage.xaml find the Frame and make a few changes to change the default from Home.xaml to our Search and making some other default changes as well.  Your Frame XAML should now look like this:

   1: <navigation:Frame x:Name="ContentFrame" Style="{StaticResource ContentFrameStyle}" 
   2:               Source="/Search" Navigated="ContentFrame_Navigated" NavigationFailed="ContentFrame_NavigationFailed">
   3: <navigation:Frame.UriMapper>
   4:   <uriMapper:UriMapper>
   5:     <uriMapper:UriMapping Uri="" MappedUri="/Views/Search.xaml"/>
   6:     <uriMapper:UriMapping Uri="/{pageName}" MappedUri="/Views/{pageName}.xaml"/>
   7:   </uriMapper:UriMapper>
   8: </navigation:Frame.UriMapper>
   9: </navigation:Frame>

Because we don’t need the Home.xaml anymore, go ahead and delete it from the project.  Also add a new view called History.xaml and alter the MainPage.xaml LinksBorder area to include a link to that:

   1: <Border x:Name="LinksBorder" Style="{StaticResource LinksBorderStyle}">
   2:     <StackPanel x:Name="LinksStackPanel" Style="{StaticResource LinksStackPanelStyle}">
   4:         <HyperlinkButton x:Name="Link1" Style="{StaticResource LinkStyle}" 
   5:                          NavigateUri="/Search" TargetName="ContentFrame" Content="home"/>
   7:         <Rectangle x:Name="Divider1" Style="{StaticResource DividerStyle}"/>
   9:         <HyperlinkButton x:Name="Link2" Style="{StaticResource LinkStyle}" 
  10:                          NavigateUri="/History" TargetName="ContentFrame" Content="history"/>
  12:         <Rectangle x:Name="Divider2" Style="{StaticResource DividerStyle}"/>
  14:         <HyperlinkButton x:Name="Link3" Style="{StaticResource LinkStyle}" 
  15:                          NavigateUri="/About" TargetName="ContentFrame" Content="about"/>
  17:     </StackPanel>
  18: </Border>

Now our rendering if we run it should look like this:

Final layout rendered

Now that we’ve got the basics of the layout, let’s start adding data in part 3.

| Comments

This is part 3 in a series on getting started with Silverlight.  To view the index to the series click hereYou can download the completed project files for this sample application in C# or Visual Basic.

Now that we have our initial layout outlined and some controls to work with, let’s start getting the data.  Since we’re going to use Twitter search, we’ll be leveraging their web service API.  In our application we won’t be hosting our own database or anything but I did want to point out the various ways you can access data via Silverlight before we go to work on ours.

Data access options

One of the bigger beginner misconceptions about accessing data in Silverlight is people looking for some ADO.NET class library in Silverlight.  Stop looking, it isn’t there.  Remember, Silverlight is a client technology that is deployed over the Internet.  You wouldn’t want a browser plug-in to have direct access to your database…as you’d have to expose your database directly to the web.  We all know that is generally a big no-no.

So the next logical step is to expose data via service layers.  This is how Silverlight can communicate with data.  Here are the primary means:

  • Web services: SOAP, ASP.NET web services (ASMX), WCF services, POX, REST endpoints
  • Sockets: network socket communication
  • File: accessing static content via web requests.


Sockets are probably the most advanced data access endpoints.  These require a socket host to exist and, at the time of this writing, also require communication over a specific port range.  If this is acceptable for you, this can be a very efficient and powerful means of communication for your application.  I don’t think, however, that this is going to be the norm if your application is public facing on the web – I see sockets right now being more for business applications.  Some resources for Sockets:

Working with Sockets requires you to really understand your deployment scenario first before you jump right in and think this will be the best method.

File Access

Silverlight can communicate with local data or data on the web.  For local data access, the application does not have direct access to the file system, but rather can read/write data via user-initiated actions using the OpenFileDialog and SaveFileDialog APIs to request and save streams of data to the local user’s machine.

Additionally, you can use plain text files or XML files on the web and have your Silverlight application use standard HTTP commands to read/write that information.  Here’s some helper information on using some of these methods:

You may find yourselves using these techniques to save settings-based data or use very simple data access.

Web Services

This is the heart of accessing data in Silverlight – through a service layer.  Silverlight supports accessing standard ASP.NET web services (ASMX) or WCF-based services using the familiar Add Service Reference methods in Visual Studio that will generate strongly-typed proxy code for you.

Additionally you can use the standard HTTP verbs to access more POX (Plain old XML) or REST-based endpoints.  Understanding how to consume these various service types is probably the best time spent a developer can educate themselves on understanding what will be right for their scenario.  Here’s some resources:

The third point there, .NET RIA Services, is a new framework that aims to make accessing data simpler and more familiar.  The link to the video will walk you through an introduction of that topic.  RIA Services is best when you own the database and are hosting services in the same web application that will be serving up the Silverlight application.

Asynchronous access

All data access in Silverlight is asynchronous.  This is perhaps another area that gets typical web developers tripped up initially.  For example in the server world it would be reasonable to see something like this:

   1: MyWebService svc = new MyWebService();
   2: string foo = svc.GetSomeValue();
   3: MyTextBox.Text = foo;

In Silverlight you wouldn’t be able to do that synchronous call.  To those who haven’t done asynchronous programming before this can be confusing, but it is well worth the learn and will make you a better developer.  Using the above pseudo code, in Silverlight you’d do something like this:

   1: MyWebService svc = new MyWebService();
   2: svc.Completed += new CompletedHandler(OnCompleted);
   3: svc.GetSomeValue();
   5: void OnCompleted(object sender, EventArgs args)
   6: {
   7:     MyTextBox.Text = args.Result;
   8: }

Notice that you use the result of the service call in a completed event handler.  This is the pattern that you will see over and over again with basic service access.

Cross-domain data access

Since Silverlight is a web client technology, it operates in the browser’s secure sandbox area and are limited to certain access policies.  One of these restrictions is referred to as cross-domain access.  That is that your application hosted in one domain cannot access services in another domain unless the service says you can.  This “opt-in” approach is commonly known as cross-domain policy files.  Silverlight, like other rich client plug-ins, conforms to these policies.  This is an area that you as a Silverlight developer will likely hit at some point.  Educate yourself sooner than later.  Here are some pointers:

In our Twitter application, we actually will be accessing a service hosted elsewhere and will need to conform to these policies.  Luckily, the search API for Twitter enables this access through their cross-domain policy file (http://search.twitter.com/crossdomain.xml). The other areas of Twitter do NOT, which is why, for now, you would not be able to access them directly through Silverlight.  In this situation you would proxy those service calls through your own service that you could enable cross-domain access via a policy file for Silverlight.  Confusing?  It’s simpler than it sounds.

COMMON MYTH: You need the Silverlight and the Adobe cross-domain policy files in your service to enable access.  This is NOT TRUE and I see it to often people saying I have crossdomain.xml and clientaccesspolicy.xml and it still doesn’t work.  If you are building a service for Silverlight consumption via cross-domain, you only need the clientaccesspolicy.xml file format – that is what we look for first and is the most flexible and secure for Silverlight.

Now that we have a high-level overview, let’s start accessing our data!

Calling the Twitter API

The Twitter search API is a simple REST-based API that we’ll only really be calling GET requests on in our application.  The format they provide is the Atom specification which makes our job a lot easier because it is a standard format and Silverlight has framework libraries that support direct consumption of that format.

We will initiate calling the API when the user clicks the SEARCH button in our application and there is content in the search input box.  Let’s wire up an even to the click button like we did in step 1 in our Hello World application.  In our Search.xaml I’m adding the click event to our SearchButton.  Add the Click event handler to the SearchButton and use the name SearchForTweets as the function name:

   1: <Button x:Name="SearchButton" Width="75" Content="SEARCH" Click="SearchForTweets" />

In Visual Studio, if you right-click now on the function name, you can Navigate to Event Handler and it will generate the stub code for you in the code page.  In this function we’re going to search the Twitter API for postings matching our criteria.  Since the API is a simple REST GET call, we’re going to use the simple WebClient Silverlight API.  This is the simplest networking API to use and allows you to read/write data via GET/POST commands as long as you don’t need to alter headers.  Before we do that I’m going to set up some member variables for some tracking that we’ll use to monitor our search terms:

   1: const string SEARCH_URI = "http://search.twitter.com/search.atom?q={0}&since_id={1}";
   2: private string _lastId = "0";
   3: private bool _gotLatest = false;

Now we can wire up our SearchForTweets function.  Remember that I mentioned that network activity is asynchronous in Silverlight?  This is where we will start experiencing this.  We’re going to use the OpenRead API on WebClient.  Because the function will be asynchronous, we’ll need to wire up a Completed event handler to receive the response and do whatever we need with it.  Here’s what we have so far:

   1: private void SearchForTweets(object sender, RoutedEventArgs e)
   2: {
   3:     WebClient proxy = new WebClient();
   4:     proxy.OpenReadCompleted += new OpenReadCompletedEventHandler(OnReadCompleted);
   5:     proxy.OpenReadAsync(new Uri(string.Format(SEARCH_URI, HttpUtility.UrlEncode(SearchTerm.Text), _lastId)));
   6: }
   8: void OnReadCompleted(object sender, OpenReadCompletedEventArgs e)
   9: {
  10:     throw new NotImplementedException();
  11: }

Notice we first create a new WebClient instance.  Then we set up the completed event handler, and finally call the OpenReadAsync funciton with a formatted URI.  The result in our completed handler (e.Result) will be a stream.  Because we are going to manipulate the response a bit and do some databinding, we’re going to create a local class to represent the structure of our search result.  I called mine TwitterSearchResult.cs and is just a class file in my project under a folder called Model:

   1: using System;
   2: using System.Windows.Media;
   4: namespace TwitterSearchMonitor.Model
   5: {
   6:     public class TwitterSearchResult
   7:     {
   8:         public string Author { get; set; }
   9:         public string Tweet { get; set; }
  10:         public DateTime PublishDate { get; set; }
  11:         public string ID { get; set; }
  12:         public ImageSource Avatar { get; set; }
  13:     }
  14: }

With our model in place we can shape the result and do some data binding.

Other networking options: HttpWebRequest and ClientHttp

There are two other network APIs we could have used to access the Twitter API: HttpWebRequest and ClientHttp.  HttpWebRequest is essentially what we *are* using with WebClient as it is a simple wrapper around that API.  If you needed more granular control over the headers in the request, you’d want to use HttpWebRequest.  Both WebClient and HttpWebRequest make use of the browser’s networking stack.  This presents some limitations, namely not being able to receive all complete status codes or leverage some expanded verbs (PUT/DELETE).  Silverlight has also introduced a ClientHttp option and uses a custom networking stack that enables you to use more verbs as well as receive status code results beyond 200/404.

More information:

As an example if we wanted to use ClientHttp, our call would look like this:

   1: private void SearchForTweets(object sender, RoutedEventArgs e)
   2: {
   3:     bool httpBinding = WebRequest.RegisterPrefix("http://search.twitter.com", 
   4:                 WebRequestCreator.ClientHttp);
   5:     WebClient proxy = new WebClient();
   6:     proxy.OpenReadCompleted += new OpenReadCompletedEventHandler(OnReadCompleted);
   7:     proxy.OpenReadAsync(new Uri(string.Format(SEARCH_URI, HttpUtility.UrlEncode(SearchTerm.Text))));
   8: }

Note that we *are not* using this method, but just wanted to point these out for you.  The call to RegisterPrefix denotes that we registered it to use the ClientHttp networking stack instead of the browser’s networking stack.  In the above sample we registered only calls to the Twitter search domain, but we could have enabled it for all HTTP requests as well.

These are additional options for you to consider in your applications.

Start simple binding some data with smart objects

Because our application is going to ‘monitor’ search terms in Twitter, we want to really just set up binding to an object collection once, and then just manipulate that collection (in our case, add to it).  To do this we are going to use two helpful objects in Silverlight: ObservableCollection<T> and PagedCollectionViewObservableCollection is a collection type that automatically provides notifications when items are modified within the collection (added, removed, changed).  PagedCollectionView will be used to help us automatically give some sorting to our objects. 

We’ll create these as member variables in our project:

   1: ObservableCollection<TwitterSearchResult> searchResults = new ObservableCollection<TwitterSearchResult>();
   2: PagedCollectionView pcv;

Now that we have the member variables, let’s initialize the PagedCollectionView in the constructor of the control so it will be available quickly.  We also want to bind our UI to our elements in the XAML.  It is good practice not to do anything to your UI in the constructor of your UserControl (in our case Search.xaml).  Because of this we’ll add a Loaded event handler in the constructor and set up the initial binding in that handler.  Our combination of constructor and Loaded event handler now looks like this:

   1: public Search()
   2: {
   3:     InitializeComponent();
   5:     pcv = new PagedCollectionView(searchResults);
   6:     pcv.SortDescriptions.Add(new System.ComponentModel.SortDescription("PublishDate", System.ComponentModel.ListSortDirection.Ascending));
   8:     Loaded += new RoutedEventHandler(Search_Loaded);
   9: }
  11: void Search_Loaded(object sender, RoutedEventArgs e)
  12: {
  13:     SearchResults.ItemsSource = pcv;
  14: }

Notice that in the loaded handler we set the ItemsSource property of our DataGrid (SearchResults) to be the PagedCollectionView that is sorted (see the SortDescription we added in line 6 above).  Now our UI is bound to this PagedCollectionView…so we should probably populate it.  Remember that it is actually a view of the data in our ObservableCollection<TwitterSearchResult> – so that is what we need to add items to in order for some data to be seen.

Populating our ObservableCollection

Now go back to the OnReadCompleted function we had before that will fire after our network request to the search API.  We now are going to populate our ObservableCollection in this function.  Here’s the code we’ll use to do that:

   1: void OnReadCompleted(object sender, OpenReadCompletedEventArgs e)
   2: {
   3:     if (e.Error == null)
   4:     {
   5:         _gotLatest = false;
   6:         XmlReader rdr = XmlReader.Create(e.Result);
   8:         SyndicationFeed feed = SyndicationFeed.Load(rdr);
  10:         foreach (var item in feed.Items)
  11:         {
  12:             searchResults.Add(new TwitterSearchResult() { Author = item.Authors[0].Name, ID = GetTweetId(item.Id), Tweet = item.Title.Text, PublishDate = item.PublishDate.DateTime.ToLocalTime(), Avatar = new BitmapImage(item.Links[1].Uri) });
  13:             _gotLatest = true;
  14:         }
  16:         rdr.Close();
  17:     }
  18:     else
  19:     {
  20:         ChildWindow errorWindow = new ErrorWindow(e.Error);
  21:         errorWindow.Show();
  22:     }
  23: }
  25: private string GetTweetId(string twitterId)
  26: {
  27:     string[] parts = twitterId.Split(":".ToCharArray());
  28:     if (!_gotLatest)
  29:     {
  30:         _lastId = parts[2].ToString();
  31:     }
  32:     return parts[2].ToString();
  33: }

A few things are happening here.  First, the e.Result matches the Stream of response we’ll get from a successfull search.  If an error occurs, we’ll use the ErrorWindow template which is provided for us in the navigation application template we chose.  The _gotLatest member variable helps us track the whether or not we need to reset the max value (which is so future queries request only the latest since the previous query).  After we get the stream we load it into an XmlReader for ease of parsing with our SyndicationFeed class.  SyndicationFeed is a class in the System.ServiceModel.Syndication library that you’ll have to add a reference too in your project.  It has built-in functions for parsing known syndication formats, like RSS and Atom.

NOTE (Here be dragons): System.ServiceMode.Syndication brings with it other dependency assemblies.  It is not a small library, but convenient to have.  Take caution in using it for your project and know when and why you need it.  We are using it here so you can be aware of the features and productivity benefits.  An alternative method (especially for just reading syndicated feeds) would be to actually just use LINQ to XML and query the resulting XDocument after loading it.  Again, for demonstration purposes, I wanted to point out the productivity use of SyndicationFeed as a strongly-typed class available to you. 

More information about reading Syndication data can be found here:

Once we have the SyndicationFeed data loaded, we simply iterate through it and add a new TwitterSearchResult to our ObservableCollection<TwitterSearchResult> object.  You’ll notice we’re doing some conversion on the Image URI to an ImageSource for easier binding later.  Additionally, we’re parsing out the ID of the tweet so we can set the first result (which is the latest) as the most recent ID for later querying (_lastId).

Giving feedback back to our users

In our final step here, we want to make sure we are giving some feedback to our users that we are doing something (searching).  Luckily we have something easy for you in an ActivityControl.  At the time of this writing, the ActivityControl was a part of the .NET RIA Services templates, but you can get it here on David Poll’s blog.  You’ll have to build the control and then add a reference to it in your project (if you download the source to our projects the binary is already included in the Libraries folder for you).

UPDATE NOTE: While the contents of this tutorial remains unchanged, the ActivityControl is now called the BusyIndicator and is released as a part of the Silverlight Toolkit.  Following the same techniques you can get the official control from the toolkit and have it deployed with your application.  No more need to compile on your own.

Once you have the reference, then you’ll add the same xmlns notation in your Search.xaml like we did with the DataGrid in step 2.  Then add the control as the root control and the Grid as it’s child.  My resulting Search.xaml now looks like this:

   1: <navigation:Page 
   2:            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   4:            xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
   5:            xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
   6:            mc:Ignorable="d"
   7:            xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
   8:            xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data" x:Class="TwitterSearchMonitor.Views.Search"
   9:            xmlns:activity="clr-namespace:System.Windows.Controls;assembly=ActivityControl"
  10:            d:DesignWidth="640" d:DesignHeight="480"
  11:            Title="Twitter Search Page">
  12:     <activity:Activity x:Name="ActivityIndicator">
  13:         <Grid x:Name="LayoutRoot">
  14:             <Grid.RowDefinitions>
  15:                 <RowDefinition Height="32"/>
  16:                 <RowDefinition/>
  17:             </Grid.RowDefinitions>
  19:             <StackPanel HorizontalAlignment="Left" Margin="0,-32,0,0" VerticalAlignment="Top" Grid.Row="1" Orientation="Horizontal">
  20:                 <TextBox x:Name="SearchTerm" FontSize="14.667" Margin="0,0,10,0" Width="275" TextWrapping="Wrap"/>
  21:                 <Button x:Name="SearchButton" Width="75" Content="SEARCH" Click="SearchForTweets" />
  22:             </StackPanel>
  23:             <data:DataGrid x:Name="SearchResults" Margin="0,8,0,0" Grid.Row="1"/>
  24:         </Grid>
  25:     </activity:Activity>
  26: </navigation:Page>

In our code for starting the search (SearchForTweets) simply add the line:

   1: ActivityIndicator.IsActive = true;

and when the OnReadCompleted event is done add the line:

   1: ActivityIndicator.IsActive = false;

And you’ll have visual progress to the end user.  At this point we can run our application (F5) and enter a search term.  You’ll see the activity control:

ActivityControl view

And then the resulting view of results in the DataGrid:

Search result view

Add some monitoring via timers

Now since we call this a monitoring service, we want the search to automatically refresh for us.  Silverlight provides a few different ways to trigger automatic activity.  We’re going to use a DispatcherTimer for our application.  This is nothing more than a timer that fires a Tick event handler at our defined interval.  We’ll add another member variable:

   1: DispatcherTimer _timer;

and then in the constructor initiate our timer with adding an event handler:

   1: double interval = 30.0;
   3: _timer = new DispatcherTimer();
   4: #if DEBUG
   5: interval = 10.0;
   6: #endif
   7: _timer.Interval = TimeSpan.FromSeconds(interval);
   8: _timer.Tick += new EventHandler(OnTimerTick);

Now we want to refactor some code, because we want the SearchForTweets to be fired on the timer tick event.  We’re going to use Visual Studio refactoring tools to extract the method function code from SearchForTweets into a new method SearchForTweetsEx which we’ll call in our Tick event handler OnTimerTick.  We’ll also modify our Loaded event to actually start the timer and start the initial search for us (note our Timer is going to have a DEBUG interval of 10 seconds, otherwise 30 seconds).  Our refactored complete Search.xaml.cs now looks like this:

   1: using System;
   2: using System.Collections.ObjectModel;
   3: using System.Net;
   4: using System.Net.Browser;
   5: using System.ServiceModel.Syndication;
   6: using System.Windows;
   7: using System.Windows.Browser;
   8: using System.Windows.Controls;
   9: using System.Windows.Data;
  10: using System.Windows.Media.Imaging;
  11: using System.Windows.Navigation;
  12: using System.Windows.Threading;
  13: using System.Xml;
  14: using TwitterSearchMonitor.Model;
  16: namespace TwitterSearchMonitor.Views
  17: {
  18:     public partial class Search : Page
  19:     {
  20:         const string SEARCH_URI = "http://search.twitter.com/search.atom?q={0}&since_id={1}";
  21:         private string _lastId = "0";
  22:         private bool _gotLatest = false;
  23:         ObservableCollection<TwitterSearchResult> searchResults = new ObservableCollection<TwitterSearchResult>();
  24:         PagedCollectionView pcv;
  25:         DispatcherTimer _timer;
  27:         public Search()
  28:         {
  29:             InitializeComponent();
  31:             // set interval value for Timer tick
  32:             double interval = 30.0;
  34:             _timer = new DispatcherTimer();
  35: #if DEBUG
  36:             interval = 10.0;
  37: #endif
  38:             _timer.Interval = TimeSpan.FromSeconds(interval);
  39:             _timer.Tick += new EventHandler(OnTimerTick);
  41:             // initialize our PagedCollectionView with the ObservableCollection
  42:             // and add default sort
  43:             pcv = new PagedCollectionView(searchResults);
  44:             pcv.SortDescriptions.Add(new System.ComponentModel.SortDescription("PublishDate", System.ComponentModel.ListSortDirection.Descending));
  46:             Loaded += new RoutedEventHandler(Search_Loaded);
  47:         }
  49:         void OnTimerTick(object sender, EventArgs e)
  50:         {
  51:             SearchForTweetsEx();
  52:         }
  54:         void Search_Loaded(object sender, RoutedEventArgs e)
  55:         {
  56:             SearchResults.ItemsSource = pcv; // bind the DataGrid
  57:             _timer.Start(); // start the timer
  58:             SearchForTweetsEx(); // do the initial search
  59:         }
  61:         // Executes when the user navigates to this page.
  62:         protected override void OnNavigatedTo(NavigationEventArgs e)
  63:         {
  64:         }
  66:         private void SearchForTweets(object sender, RoutedEventArgs e)
  67:         {
  68:             SearchForTweetsEx();
  69:         }
  71:         /// <summary>
  72:         /// Method that actually does the work to search Twitter
  73:         /// </summary>
  74:         private void SearchForTweetsEx()
  75:         {
  76:             if (!string.IsNullOrEmpty(SearchTerm.Text))
  77:             {
  78:                 _timer.Stop(); // stop the timer in case the search takes longer than the interval
  79:                 ActivityIndicator.IsActive = true; // set the visual indicator
  81:                 // do the work to search twitter and handle the completed event
  82:                 WebClient proxy = new WebClient();
  83:                 proxy.OpenReadCompleted += new OpenReadCompletedEventHandler(OnReadCompleted);
  84:                 proxy.OpenReadAsync(new Uri(string.Format(SEARCH_URI, HttpUtility.UrlEncode(SearchTerm.Text), _lastId)));
  85:             }
  86:         }
  88:         /// <summary>
  89:         /// Method that fires after our SearchForTweetsEx runs and gets a result
  90:         /// </summary>
  91:         /// <param name="sender"></param>
  92:         /// <param name="e"></param>
  93:         void OnReadCompleted(object sender, OpenReadCompletedEventArgs e)
  94:         {
  95:             if (e.Error == null)
  96:             {
  97:                 _gotLatest = false; // reset the latest detector
  98:                 XmlReader rdr = XmlReader.Create(e.Result); // load stream into a reader
 100:                 SyndicationFeed feed = SyndicationFeed.Load(rdr);  // load syndicated feed (Atom)
 102:                 // parse each item adding it to our ObservableCollection
 103:                 foreach (var item in feed.Items)
 104:                 {
 105:                     searchResults.Add(new TwitterSearchResult() { Author = item.Authors[0].Name, ID = GetTweetId(item.Id), Tweet = item.Title.Text, PublishDate = item.PublishDate.DateTime.ToLocalTime(), Avatar = new BitmapImage(item.Links[1].Uri) });
 106:                     _gotLatest = true; // reset the fact that we already have the max id needed
 107:                 }
 109:                 rdr.Close();  // close the reader
 110:             }
 111:             else
 112:             {
 113:                 // initialize our ErrorWindow with exception details
 114:                 ChildWindow errorWindow = new ErrorWindow(e.Error);
 115:                 errorWindow.Show();
 116:             }
 117:             ActivityIndicator.IsActive = false; // reset the UI
 118:             _timer.Start(); // reset the timer
 119:         }
 121:         /// <summary>
 122:         /// Parses out the Tweet ID from the tweet
 123:         /// </summary>
 124:         /// <param name="twitterId"></param>
 125:         /// <returns></returns>
 126:         private string GetTweetId(string twitterId)
 127:         {
 128:             string[] parts = twitterId.Split(":".ToCharArray());
 129:             if (!_gotLatest)
 130:             {
 131:                 _lastId = parts[2].ToString();
 132:             }
 133:             return parts[2].ToString();
 134:         }
 135:     }
 136: }

The flow will be that our Search page will load, start the timer and start the initial search.  After the interval time fires, the search will be executed again, but remember it will use the last known ID to start from as not to load all the repeats again.  This future search data will be added to our ObservableCollection and since the DataGrid is already bound to that, it will be automatically represented in the UI in the appropriate sort order.

We also added some checking to make sure the search term is there and we’re not searching for a blank value.


At this point of step 3 we’ve made a lot of progress. We’ve wired up a service call to a 3rd party service, hooked it up to a DataGrid using binding, and added a timer to automatically fetch the service. We could be done, but we’re not – the DataGrid isn’t exactly how we want to represent the final UI, Let’s move on to part 4 where we actually do some data templating and introduce you to the XAML binding syntax.

| Comments

UPDATED: If you found this post via a search, the below information was for Silverlight 3 beta and no longer works in Silverlight 3 release.  Click here for an updated tutorial on grouping in the Silverlight DataGrid for Silverlight 3.

I got this question on how do you add grouping to the DataGrid in Silverlight without using the RIA Services ObjectDataSource.  Frankly I didn’t know off the top of my head either and I’ve since learned it isn’t obvious.  Allow me to explain the steps.

In my simple app I have a static class that supplies some hard-coded data:

   1: public List<Person> GetPeople()
   2: {
   3:     List<Person> peeps = new List<Person>();
   4:     peeps.Add(new Person() { FirstName = "Tim", LastName="Heuer", Gender="M", AgeGroup="Adult" });
   5:     peeps.Add(new Person() { FirstName = "Lisa", LastName="Heuer", Gender="F", AgeGroup="Adult" });
   6:     peeps.Add(new Person() { FirstName = "Zoe", LastName = "Heuer", Gender="F", AgeGroup="Kid" });
   7:     peeps.Add(new Person() { FirstName = "Zane", LastName = "Heuer", Gender="M", AgeGroup="Kid" });
   8:     return peeps;
   9: }

You can see there is a Gender field and I want to list them grouped on that in a DataGrid.  So I would first add a reference to the DataGrid control library and add that:

   1: <navigation:Page x:Class="SilverlightApplication32.AboutPage" 
   2:            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   4:            xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
   5:            xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
   6:            Title="AboutPage Page">
   7:     <Grid x:Name="LayoutRoot" Background="White">
   8:         <StackPanel>
   9:             <TextBlock Text="Detail" Style="{StaticResource HeaderTextStyle}"/>
  10:             <TextBlock Text="Detail list of members with gender." Style="{StaticResource ContentTextStyle}"/>
  11:             <data:DataGrid ItemsSource="{Binding}"/>
  12:         </StackPanel>
  13:     </Grid>
  14: </navigation:Page>

Notice the xmlns attribute in the control (this is in a navigation page, but the syntax is the same).  Now how to add the grouping?  You’d hope it would be something as simple as GroupPathName on the DataGrid or something.  But remember that grouping can be done multilevel.  So to add grouping we have to do some things first.  First, add a reference to System.ComponentModel in your application.  Then add another xmlns to your control for the library, since that is where the PropertyGroupDescription is located.  The result is that we have:

   1: <navigation:Page x:Class="SilverlightApplication32.AboutPage" 
   2:            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   4:            xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
   5:            xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
   6:            xmlns:cm="clr-namespace:System.Windows.Data;assembly=System.ComponentModel"
   7:            Title="AboutPage Page">
   8:     <Grid x:Name="LayoutRoot" Background="White">
   9:         <StackPanel>
  10:             <TextBlock Text="Detail" Style="{StaticResource HeaderTextStyle}"/>
  11:             <TextBlock Text="Detail list of members with gender." Style="{StaticResource ContentTextStyle}"/>
  12:             <data:DataGrid ItemsSource="{Binding}">
  13:                 <data:DataGrid.GroupDescriptions>
  14:                     <cm:PropertyGroupDescription PropertyName="Gender" />
  15:                 </data:DataGrid.GroupDescriptions>
  16:             </data:DataGrid>
  17:         </StackPanel>
  18:     </Grid>
  19: </navigation:Page>

Notice the ComponentModel use within the DataGrid’s GroupDescriptions node.  This would render in a UI like:

DataGrid single grouping

Want to add multilevel grouping? Just add another PropertyGroupDescription:

   1: <data:DataGrid ItemsSource="{Binding}">
   2:     <data:DataGrid.GroupDescriptions>
   3:         <cm:PropertyGroupDescription PropertyName="Gender" />
   4:         <cm:PropertyGroupDescription PropertyName="AgeGroup" />
   5:     </data:DataGrid.GroupDescriptions>
   6: </data:DataGrid>

And it will render top-down:

DataGrid multilevel grouping

You can also do this in code of course like this (assuming the DataGrid is named “MyGrid”:

   1: MyGrid.GroupDescriptions.Add(new PropertyGroupDescription("Gender"));

I found this information on one of our tester’s site, Naga Satish.  Naga also has some other valuable DataGrid information:

I recommend you bookmark a few :-).