If you hadn’t noticed, behaviors created in Silverlight 3 beta will be broken in Silverlight 3 release. The reason for this is that the assembly Microsoft.Expression.Interactivty.dll (that used to be found in C:\Program Files\Microsoft Expression\Blend 3\Libraries\Silverlight\v3.0) no longer exists. Instead, it’s replaced by System.Windows.Interactivity.dll (which is found in C:\Program Files\Microsoft SDKs\Expression\Blend 3\Interactivity\Libraries\Silverlight). Seems simple enough, sure, but it took a good hour (with fists clenched) for me to work this out today since I couldn’t find any docs on it at all.

So, to turn this rant into something useful, I’ll talk about a useful trigger for grabbing a double click on UIElements (such as DataGrid).

The scenario is you have a list of items displayed in a DataGrid and want to select one by double clicking it. We’ll need to code two classes: 1. a trigger that fires on double click; 2. an action that can be fired in response to the trigger (e.g. an action that executes an ICommand).

The first step, is to create the trigger .cs file. Visual Studio 2008 and Blend 3 now provide templates for Triggers, Actions & Behaviors to get you started. Here’s what the template looks like in Visual Studio:

This creates the class, adds the necessary overrides and adds a reference to System.Windows.Interactivity.dll.

Now to implement the double click trigger. There’s not a lot of mystery about how to do this, and I borrowed the logic from this useful blog post: Silverlight 3 Behaviors : Double Click Trigger – but extended it in several key areas.

Firstly, I used UIElement.Addhandler() to attach the mouse events (MouseLeftButtonDown, MouseLeftButtonUp) in order to ensure the trigger works on UIElements that mark these events handled (like Button for instance).

Secondly, I wanted to be selective and intelligent about the parameter passed in to TriggerBase.InvokeActions(). The important thing here is that, in different circumstances, I’ll want to pass in different parameters. For instance, if the control that fired the trigger is a DataGrid, I’ll want to pass in the SelectedItem; if the control is a Selector, I’ll want to pass in the SelectedItem; or if the control is something else, I may want to pass in the DataContext.

In order to be as generic and extensible as possible, I decided to build a base class that I could inherit other classes from. Here’s my implementation:

using System;
using System.Windows;
using System.Windows.Threading;
using System.Windows.Input;
using System.Windows.Interactivity;

namespace GridClicker.Behaviors
{
    public class DoubleClickTriggerBase : TriggerBase<UIElement>
    {
        private readonly DispatcherTimer _timer;

        public DoubleClickTriggerBase()
        {
            _timer = new DispatcherTimer
            {
                Interval = new TimeSpan(0, 0, 0, 0, 200)
            };
            _timer.Tick += OnTimerTick;
        }

        protected override void OnAttached()
        {
            base.OnAttached();
            AssociatedObject.AddHandler(UIElement.MouseLeftButtonDownEvent,
                                        new MouseButtonEventHandler(OnMouseAction), true);
        }

        protected override void OnDetaching()
        {
            base.OnDetaching();
            AssociatedObject.RemoveHandler(UIElement.MouseLeftButtonDownEvent,
                                           new MouseButtonEventHandler(OnMouseAction));
            if (_timer.IsEnabled)
            {
                _timer.Stop();
            }
        }

        private void OnMouseAction(object sender, MouseButtonEventArgs e)
        {
            if (!_timer.IsEnabled)
            {
                _timer.Start();
                return;
            }
            _timer.Stop();
            DoInvoke();
        }

        private void OnTimerTick(object sender, EventArgs e)
        {
            _timer.Stop();
        }

        protected virtual void DoInvoke()
        {
            InvokeActions(null);
        }
    }
}

The key thing here is the virtual DoInvoke() method that can be overridden in descendent classes if a special value need to be passed as parameter to InvokeActions().

Here’s an inherited class, DataGridDoubleClickTrigger.cs:

using System.Windows.Controls;

namespace GridClicker.Behaviors
{
    public class DataGridDoubleClickTrigger : DoubleClickTriggerBase
    {
        protected override void DoInvoke()
        {
            var dg = AssociatedObject as DataGrid;
            var o = dg == null ? null : dg.SelectedItem;
            if (o != null)
            {
                InvokeActions(o);
            }
        }
    }
}

This simply passes in the SelectedItem of the DataGrid as the InvokeAction() parameter. Of course you could make any number of classes that inherit from DoubleClickTriggerBase. I should point out that there is an assumption here that the user will double click on a row of the DataGrid and not the header, though it will not break in any case. If a user does double click on the header of the DataGrid, if the SelectedItem is not null it will be returned, otherwise nothing will happen.

Now a trigger is no good without an action to fire, so here is a very quick and simplistic action that executes an ICommand. Firstly, create the action in Visual Studio:

And here’s the implementation:

using System.Windows;
using System.Windows.Input;
using System.Windows.Interactivity;

namespace GridClicker.Behaviors
{
    public class ExecuteCommandAction : TriggerAction<FrameworkElement>
    {
        public string CommandName { get; set; }

        protected override void Invoke(object o)
        {
            if (CommandName == null) return;
            var dataContext = AssociatedObject.DataContext;
            if (dataContext == null) return;
            var command = dataContext.GetType().GetProperty(CommandName).GetValue(dataContext, null) as ICommand;
            if (command != null && command.CanExecute(o))
            {
                command.Execute(o);
            }
        }
    }
}

Even though TriggerAction is a DependencyObject, it doesn’t seem to want to let you make CommandName a DependencyProperty and bind it’s value. No idea why this is, hence the roundabout route to grab the command.

To put it altogether, here is the XAML:

<StackPanel x:Name="ContentStackPanel">

    <TextBlock x:Name="HeaderText" Style="{StaticResource HeaderTextStyle}" 
                       Text="Home"/>

    <data:DataGrid ItemsSource="{Binding Categories}" IsReadOnly="True">
        <i:Interaction.Triggers>
            <b:DataGridDoubleClickTrigger>
                <b:ExecuteCommandAction CommandName="SelectCommand" />
            </b:DataGridDoubleClickTrigger>
        </i:Interaction.Triggers>
    </data:DataGrid>
    
    <Button Content="Double Click Button" Margin="10" VerticalAlignment="Center" HorizontalAlignment="Center">
        <i:Interaction.Triggers>
            <b:DoubleClickTriggerBase>
                <b:ExecuteCommandAction CommandName="ButtonCommand"/>
            </b:DoubleClickTriggerBase>
        </i:Interaction.Triggers>
    </Button>

</StackPanel>

Note that I also put in a Button that demonstrates that the base class – DoubleClickTriggerBase - is useful in instances where you have no need to pass a parameter to the InvokeActions().

Finally, to round things off, here is the view’s presenter:

public class HomePresenter : INotifyPropertyChanged
{
    public ICommand SelectCommand { get; private set; }
    public ICommand ButtonCommand { get; private set; }

    public HomePresenter()
    {
        SelectCommand = new DelegateCommand<object>(o =>
        {
            var cat = o as Category;
            var dw = new DetailsWindow {Width = 300.0, Height = 300.0};
            var g = dw.FindName("LayoutRoot") as Grid;
            g.Children.Add(new TextBlock() 
            { 
                Text = "Category Name: " + cat.CategoryName,
                HorizontalAlignment = HorizontalAlignment.Center,
                VerticalAlignment = VerticalAlignment.Center
            });
            dw.Show();
        });

        ButtonCommand = new DelegateCommand<object>(o => HtmlPage.Window.Alert("Button was double clicked!"));
    }

    public ObservableCollection<Category> Categories
    {
        get { return CategoryHelper.GetCategories(); }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

In the example I am using Prism’s DelegateCommand implementation of ICommand.

There you have it!

Source Code

A question I asked myself the other day was 'what is the most elegant way to show a confirm dialogue to a user?' Now there's nothing hard about
doing this and we all do it from time to time, but nevertheless there are many different ways one might go about doing it. My particular concern
was firstly to invoke ICommands from the user action and secondly avoid triggering UI events from my presenter (i.e. opening dialogues).

The first and most obvious technique is to simply show a confirm in the event handler of the button in code behind.

Take the following XAML:

<data:DataGrid ItemsSource="{Binding Categories}" AutoGenerateColumns="False">
    <data:DataGrid.Columns>
        <data:DataGridTextColumn Header="ID" Binding="{Binding CategoryID}" />
        <data:DataGridTextColumn Header="Name" Binding="{Binding CategoryName}" />
        <data:DataGridTemplateColumn Header="">
            <data:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <Button Content="Delete" Click="Button_Click" />
                </DataTemplate>
            </data:DataGridTemplateColumn.CellTemplate>
        </data:DataGridTemplateColumn>
    </data:DataGrid.Columns>
</data:DataGrid>

and the click handler in the code-behind:

private void Button_Click(object sender, RoutedEventArgs e)
{
	Category cat = (sender as Button).DataContext as Category;    
	if (HtmlPage.Window.Confirm("Are you sure you want to delete that?"))    
	{        
		HtmlPage.Window.Alert("Deleted");    
	}
}

This works perfectly well, and looks something like this:

Not a good solution in my case, however, as I wanted to use commanding to link my Delete button to an ICommand in the view’s presenter. (Prism gives a great implementation of ICommand – DelegateCommand<T>).

When you use commanding, the obvious place to put the confirm dialogue is in the presenter:

<data:DataGrid ItemsSource="{Binding Categories}" AutoGenerateColumns="False">
    <data:DataGrid.Columns>
        <data:DataGridTextColumn Header="ID" Binding="{Binding CategoryID}" />
        <data:DataGridTextColumn Header="Name" Binding="{Binding CategoryName}" />
        <data:DataGridTemplateColumn Header="">
            <data:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <Button Content="Delete" cal:Click.Command="{Binding Path=Value, Source={StaticResource DeleteCommand}}" 
                            cal:Click.CommandParameter="{Binding}"/>
                </DataTemplate>
            </data:DataGridTemplateColumn.CellTemplate>
        </data:DataGridTemplateColumn>
    </data:DataGrid.Columns>
</data:DataGrid>

and the DelegateCommand in the presenter:

DeleteCommand = new DelegateCommand<Category>((cat) =>
    {
        if (HtmlPage.Window.Confirm("Are you sure you want to delete that?"))
        {
            HtmlPage.Window.Alert("Deleted");
        }
    });

NOTE: Of course there’s an obvious problem with binding to an ICommand inside a DataTemplate – the DataContext is not the view (e.g. the view model or presenter) but the particular data item that the DataTemplate is displaying. You can get around this using RelativeSource binding in WPF, but not in Silverlight. The solution is to make your ICommand a StaticResource using a implementation of ObservableCommand, as described here: http://msdn.microsoft.com/en-us/library/dd458928.aspx

Now in the example above, the confirm dialogue certainly displays as I’d like it to, but I have philosophical objections to taking UI components (i.e. the dialogue) out of the view and sticking it in the presenter. Doing this also makes unit testing in the presenter a lot more difficult.

The first alternative that came to mind was to use the code-behind again, but this time invoke the ICommand from there, like this:

private void Click1(object sender, RoutedEventArgs e)
{
    ((HomePagePresenter)DataContext).DeleteCommand.Execute((sender as Button).DataContext as Category);
}

This is actually a fairly nice solution- the separation between the presenter and the view is maintained, the inconvenience of declaring the ICommand as a StaticResource is avoided, and it’s quite intuitive. It still seems a little inelegant, however – since all XAML purists will tell you that binding is better in every case.

The next solution I implemented is really nice. I created a new attached behaviour that extends Prism’s CommandBehaviorBase<T> called ConfirmClick. This lets me use the following mark-up:

<data:DataGrid ItemsSource="{Binding Categories}" AutoGenerateColumns="False" Grid.Row="1">
    <data:DataGrid.Columns>
        <data:DataGridTextColumn Header="ID" Binding="{Binding CategoryID}" />
        <data:DataGridTextColumn Header="Name" Binding="{Binding CategoryName}" />
        <data:DataGridTemplateColumn Header="">
            <data:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <Button Content="Delete" cal2:ConfirmClick.Command="{Binding Path=Value, Source={StaticResource DeleteCommand}}"
                            cal2:ConfirmClick.CommandParameter="{Binding}"/>
                </DataTemplate>
            </data:DataGridTemplateColumn.CellTemplate>
        </data:DataGridTemplateColumn>
    </data:DataGrid.Columns>
</data:DataGrid>

I won’t include the two files ButtonBaseConfirmClickCommandBehavior.cs & ConfirmClick.cs here as they are quite lengthy, but download the source code at the end of this post if you want them.

This approach totally abstracts the out the creation of the confirm dialogue so I don’t have to think about it at all. It’s neat, reusable and fits the pattern perfectly.

I could have stopped here, but there was one other avenue I wanted to check: the new Behaviours that come as part of Silverlight 3. Behaviours are divided into three broad categories: Triggers, Actions and Behaviors. In my case, I can use the inbuilt EventTrigger trigger and attach it to the Click event of my Button.

Don’t forget that if you want to use Behaviors, you need to reference Microsoft.Expression.Interactivity.dll from you project and import the namespace into the XAML.

Now that I can trap the Interestingly, the Microsoft.Expression.Interactivity implements an InvokeCommandAction which I couldn’t for the life of me get to work. It doesn’t help that it is not mentioned anywhere in the Silverlight 3 documentation. Not to worry, I ended up implementing my own Action which looks for an ICommand in the FrameworkElement.Tag property. Here’s the XAML:

<data:DataGrid ItemsSource="{Binding Categories}" AutoGenerateColumns="False" Grid.Row="2">
    <data:DataGrid.Columns>
        <data:DataGridTextColumn Header="ID" Binding="{Binding CategoryID}" />
        <data:DataGridTextColumn Header="Name" Binding="{Binding CategoryName}" />
        <data:DataGridTemplateColumn Header="">
            <data:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <Button Content="Delete" Tag="{Binding Path=Value, Source={StaticResource DeleteCommand}}">
                        <i:Interaction.Triggers>
                            <i:EventTrigger EventName="Click">
                                <loc:ConfirmCommandAction />
                            </i:EventTrigger>
                        </i:Interaction.Triggers>
                    </Button>
                </DataTemplate>
            </data:DataGridTemplateColumn.CellTemplate>
        </data:DataGridTemplateColumn>
    </data:DataGrid.Columns>
</data:DataGrid>

And the Action looks like this:

public class ConfirmCommandAction : TriggerAction<FrameworkElement>
{
    private string message;
    public string Message
    {
        get { return message ?? "Are you sure you want to do that?"; }
        set { message = value; }
    }
    protected override void Invoke(object parameter)
    {
        if (AssociatedObject.Tag is ICommand)
        {
            var cmnd = AssociatedObject.Tag as ICommand;
            if (cmnd != null && cmnd.CanExecute(AssociatedObject.DataContext))
            {
                if (HtmlPage.Window.Confirm(Message))
                {
                    cmnd.Execute(AssociatedObject.DataContext);
                }
            }
        }
    }
}

I should point out that my implementation of ConfirmCommandAction was pretty rapid  and has some holes in it. For instance, I’m not sure I like assuming that the DataContext of the AssociatedObject should be passed as the parameter of the ICommand. I’m also a little unsure whether the Tag property was really supposed to be used like that. Nevertheless it all works quite nicely.

So, there’s several techniques for implementing a confirm dialogue on an ICommand. I think each is valid in it’s own way, but my money is on the ConfirmClick attached behaviour as the most elegant solution – providing you’re willing to include some of the Prism libraries in your project.

Hope you find it useful!

Get the source

UPDATE: I bumped into Nikhil Kothari on Twitter and he mentioned that the eventing model for DomainContext is changing in the July CTP (going to become a lot more intuitive when dealing with multiple concurrent calls)…

The more time I spend working with .NET RIA services, the more I like it. That said, it’s not without it’s frustrations. Today I spent a good part of the afternoon writing some Silverlight test cases and found myself repeating a stack of awkward, ugly code.

Most of the example code I’ve seen around the web is pretty simplistic and doesn’t deal with DomainContext classes that make multiple calls (submits and loads). I’m sure this will change as ria services mature, but at the moment rich examples are hard to come by.

The issue I was having was tracking which call was returning in two of the main events that a DomainContext raises: Loaded and Submitted. These  events are useful in the sense that they tell you when your call has completed, but if you’ve made multiple calls simultaneously then it’s not easy to tell which call is the one that has raised the event. For instance, when the Loaded event is raised, the LoadedDataEventArgs gives you access to a LoadedEntities property which holds the collection of newly loaded entities. You could then check the type of the first entity in order to see which load call has completed, but this is not a great solution as a call may have returned null (i.e. zero results)

Enter UserState. I actually couldn’t find much documentation on this one, but in a nutshell, it is a parameter of type object that you can pass into load and submit methods of your DomainContext and get back in the LoadedDataEventArgs and SubmittedChangesEventArgs.

On the most simple level you could call a method, say, LoadById() and pass in an int, say 1. When the Loaded event is raised after the call, you get back the LoadedDataEventArgs which now carries a property called UserState which is an int with a value of 1. Nice!

After reading around a bit on the Silverlight forums, I decided on the following approach to streamline things further.

Firstly, I created a delegate in the presenter of my view.

private delegate void CompletedDelegate(EventArgs args);

Secondly, I hooked up a reusable method to the Loaded and Submitted events of my DomainContext. The idea is to take the events’ EventArgs and have a look if they have a UserState property that is the delegate type we are after. Here’s the method:

private void contextEventHandler(EventArgs args)
{
    if (args is LoadedDataEventArgs)
    {
        if (((LoadedDataEventArgs)args).UserState is CompletedDelegate)
        {
            ((CompletedDelegate)((LoadedDataEventArgs)args).UserState).Invoke(args);
        }
    }
    else if (args is SubmittedChangesEventArgs)
    {
        if (((SubmittedChangesEventArgs)args).UserState is CompletedDelegate)
        {
            ((CompletedDelegate)((SubmittedChangesEventArgs)args).UserState).Invoke(args);
        }
    }
}

And here’s the constructor of the presenter where I hooked up the method and handled events generated by the view:

public HomePagePresenter(HomePage view)
{
    this.view = view;

    catCtxt = new CategoryDomainContext();
    catCtxt.Loaded += (s, e) => contextEventHandler(e);
    catCtxt.Submitted += (s, e) => contextEventHandler(e);

    view.Click += (s, e) =>
        {
            if ((s as Button).Tag.ToString() == "Save")
            {
                catCtxt.SubmitChanges(new CompletedDelegate(dataSubmitted));
            }
            else if ((s as Button).Tag.ToString() == "Reject")
            {
                catCtxt.RejectChanges();
            }
        };

    loadData();
}

The key part of the above is catCtxt.SubmitChanges(new CompletedDelegate(dataSubmitted)); which sets the UserState as the delegate. Now, when the call to submit completes, the method dataSubmitted will be called. Here is that method:

private void dataSubmitted(EventArgs e)
{
    SubmittedChangesEventArgs args = e as SubmittedChangesEventArgs;
    if (args.Error != null)
    {
        HtmlPage.Window.Alert(args.Error.Message);
    }
    else
    {
        HtmlPage.Window.Alert("Data submission complete");
    }
}

Finally, it’s worth taking a look at the loadData() method which again passes in a delegate as UserState:

private void loadData()
{
    catCtxt.LoadCategories(null, new CompletedDelegate(dataLoaded));
}

And the dataLoaded method:

private void dataLoaded(EventArgs e)
{
    notifyChange("Categories");
}

And to road off the code bits, here’s the simplistic DomainService class I used in the example:

[EnableClientAccess()]
public class CategoryDomainService : DomainService
{
    public IQueryable<Category> GetCategories()
    {
        return CategoryHelper.GetCategories().AsQueryable();
    }

    public void InsertCategory(Category cat)
    {
    }

    public void UpdateCategory(Category newCat, Category originalCat)
    {
    }

    public void DeleteCategory(Category cat)
    {
    }
}

All in all I was pretty happy with this technique. It seemed to make ria services a little more WCF-like to me, while still retaining all the major benefits of ria services. The code is still pretty rough, but hey – all my test cases are now passing and the code is a lot more readable than it was. Happy days!

NOTE: It’s probably worth pointing out that the July CTP of ria services may well render this example obsolete when it comes out. soon i hope!!!

Get the source

I’ve spent a lot of time over the past few days playing with the new .NET RIA services which can be installed alongside Silverlight 3. RIA services are great, and one thing I’m really liking is how much old code I’ll be able to throw away (like stacks of custom WCF wrappers on the Silverlight side to manage async state and batching multiple service requests).

The original pressure for my team to adopt RIA services was mainly driven by the nice end-to-end data validation framework that it ships with. We started rolling our own and it quickly became clear how much work it was going to take, and – let’s be fair – nobody likes writing that sort of code. If you haven’t checked it out already, a good place to start is over at Brad Abrams’ blog.

A key goal of RIA services is to simplify n-tier architectures, and it does this by creating a link between a ASP.NET web application project and a Silverlight application project and generating a lot of code that is magically shared between the two. I won’t go into this in any detail, because it’s not the point of this post.

One of the big issues I hit first up is this: once you install the RIA services pack, you are given the ability to link a ASP.NET web application project with a Silverlight application, but not a Silverlight class library. My particular usage scenario means I need to share a service DLL  amongst a bunch of XAPs (i.e. modules of a Prism solution) , so it’s no good for me to have a direct link between the RIA services web app and a Silverlight app (e.g. the Prism shell). I need a library I can share between all my modules.

When you create a new web application project, you get the following option:

Alternatively, you can go into the properties of a Silverlight application and link the server project there:

But strangely enough, these options don’t exist when you are dealing with a Silverlight class library.

The work around is this: create you ASP.NET web application and then create your Silverlight class library. The two aren’t linked yet. Exit visual studio and open the .csproj file of the class library project. You want to add the following:

<PropertyGroup>
	....
	<LinkedServerProject>..\SilverlightApplication1.Web\SilverlightApplication1.Web.csproj</LinkedServerProject>
	...
</PropertyGroup>

Just make sure the path points to your web application project.

Now when you re-open visual studio and build your web application project (assuming it has some domain service classes in it) you’ll see the generated code in your Silverlight class library.

I should probably note that this will all probably change by the time the July CTP comes out (Brad Abrams implied as much in a twitter response to my question).

Wow. just realising that finding the time to write a blog is hard! I've had a busy couple of weeks, and with a big deadline looming in February I think time is only going to become more scarce. It's a good thing I really enjoy coding in Silverlight - unlike some other technologies I've been using lately - and being on the crest of this wave of Silverlight enthusiasm going around at the moment.

Last night I witnessed the first ever meeting of the Silverlight Designer and Developer Network - a new Silverlight user group here in Melbourne. Turnout was huge for a first time and the quality of the presented material was great. In particular, I have to say I was blown away by Jonas Follesø's presentation (a Norwegian Microsoft guy). Not only did he turn out *lots* of code by hand by he actually covered some really cool topics (which I didn't expect at this sort of event). He covered the Silverlight Toolkit (nothing new here), Live Mesh & Silverlight outside the browser (wow! this one got the gears of my brain turning) as well as the as-yet nameless Silverlight Business FX Framework which I'm thinking will be part of Silverlight 3 (we could take weeks/months off our project if this was available now!). So I walked away pretty happy and very positive about putting myself in the Silverlight camp for the foreseeable future.

Better get to some code....

A very quick post today. In the course of today I realised needed to unify our approach to managing the UI during asynchronous loads. Basically, the scenario is where you have a control that displays some piece of data that needs to be fetched, and the fetching may take several seconds (or more). Obviously you need to block any user interaction with the control before it is fully loaded, and to follow the convention, you should probably also throw a translucent layer over the control and display a snazzy loading graphic. And of course, a major consideration for me was to make a control I could re-use throughout my app.

Here's what I'm making:

The way I decided to approach this was to make a very minor extension to a ContentControl - adding an extra piece of content to hold the 'waiting' layer, and an IsLoading property to manage the visual state of the control (i.e. loading or normal). To manage the different visual states, Silverlight provides the handy Visual State Manager. Using the VSM, you can define the visual appearance of your control when it is in certain states (or combinations of states). The Loading Panel can only ever be in two states: Normal and Loading. When the control is in the loading state, the 'waiting' layer has it's visibility set to visible.

Here's the XAML:

<ResourceDictionary

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

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

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

    xmlns:loc="clr-namespace:LoadingPanel"

    >

    <Style TargetType="loc:LoadingPanel">

        <Setter Property="Template">

            <Setter.Value>

                <ControlTemplate TargetType="loc:LoadingPanel">

                    <Grid>

                        <vsm:VisualStateManager.VisualStateGroups>

                            <vsm:VisualStateGroup x:Name="CommonStates">

                                <vsm:VisualState x:Name="Loading">

                                    <Storyboard>

                                        <ObjectAnimationUsingKeyFrames 

                                            Storyboard.TargetName="frameworkelementLoadingContent" 

                                            Storyboard.TargetProperty="Visibility" Duration="0">

                                            <DiscreteObjectKeyFrame KeyTime="0">

                                                <DiscreteObjectKeyFrame.Value>

                                                    <Visibility>Visible</Visibility>

                                                </DiscreteObjectKeyFrame.Value>

                                            </DiscreteObjectKeyFrame>

                                        </ObjectAnimationUsingKeyFrames>

                                    </Storyboard>

                                </vsm:VisualState>

                                <vsm:VisualState x:Name="Normal"/>

                            </vsm:VisualStateGroup>

                        </vsm:VisualStateManager.VisualStateGroups>

                        <ContentPresenter Content="{TemplateBinding Content}"/>

                        <ContentPresenter x:Name="frameworkelementLoadingContent" 

                                          Content="{TemplateBinding LoadingContent}"

                                          Visibility="Collapsed"/>

                    </Grid>

                </ControlTemplate>

            </Setter.Value>

        </Setter>

    </Style>

</ResourceDictionary>  

There's little that needs explaining here, since the control comprises little more than two ContentPresenters to hold the pieces of content. The VSM also enables you to se transitions between states, but since our designers haven't asked for anything I've purposely left this out.

In our case, when the control is put into 'Loading' mode, there's a basic Storyboard with a single animation occurring after 0 seconds (the change from collapsed to visible) targeted at the 'waiting' content presenter. This particular control uses only one VisualStateGroup, but with more complex controls, you can use several of these to describe different sets of visual characteristics that may or may not be valid in conjunction with other visual states.

The LoadingPanel.cs is a little more interesting. Here's the code:

using System;

using System.Windows;

using System.Windows.Controls;

namespace LoadingPanel

{

    public class LoadingPanel : ContentControl

    {

        public LoadingPanel()

        {

            DefaultStyleKey = typeof(LoadingPanel);

            IsLoading = false;

        }

        public override void OnApplyTemplate()

        {

            base.OnApplyTemplate();

            GoToState();

        }

        private void GoToState()

        {

            if (IsLoading)

            {

                VisualStateManager.GoToState(this, "Loading", false);

            }

            else

            {

                VisualStateManager.GoToState(this, "Normal", false);

            }

        }

        public static DependencyProperty IsLoadingProperty =

            DependencyProperty.Register("IsLoading", typeof(bool), typeof(LoadingPanel),

            new PropertyMetadata(new PropertyChangedCallback((d, e) =>

            {

                LoadingPanel lp = d as LoadingPanel;

                lp.GoToState();

            })));

        public bool IsLoading

        {

            get { return (bool)GetValue(IsLoadingProperty); }

            set { SetValue(IsLoadingProperty, value); }

        }

        public static readonly DependencyProperty LoadingContentProperty =

            DependencyProperty.Register("LoadingContent", typeof(object), typeof(LoadingPanel), null);

        public object LoadingContent

        {

            get { return (object)GetValue(LoadingContentProperty); }

            set { SetValue(LoadingContentProperty, value); }

        }

    }

}

A few things worth pointing out:

• The constructor is useful for setting default values for the control's properties
• The GotoState() method is, by convention, a helper method that interacts with the VisualStateManager
• I haven't touched the Control Contract at all. This is a series of class Attributes that describe the various parts and states of the control - consumed by Blend. If you don't plan to use the control in Blend then there's  no need for a Control Contract, but apparently it's good practice to leave it in anyway. Karen Corby wrote a good post about this.

Here's how to use the control in your XAML:

<UserControl 

    x:Class="LoadingPanelSL.Page"

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

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

    xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"

    xmlns:lp="clr-namespace:LoadingPanel;assembly=LoadingPanel"

    >

    <Grid x:Name="LayoutRoot">

        <Grid Width="400" Height="400">

            <Grid.RowDefinitions>

                <RowDefinition Height="*" />

                <RowDefinition Height="Auto" />

            </Grid.RowDefinitions>

            <lp:LoadingPanel IsLoading="{Binding IsLoading}">

                <lp:LoadingPanel.Content>

                    <data:DataGrid x:Name="datagridMyGrid" ItemsSource="{Binding MyData}" />

                </lp:LoadingPanel.Content>

                <lp:LoadingPanel.LoadingContent>

                    <Grid>

                        <Rectangle Fill="LightSlateGray" Opacity="0.3" />

                        <TextBlock Text="Loading..." 

                                   HorizontalAlignment="Center" 

                                   VerticalAlignment="Center" 

                                   Opacity="0.7" FontSize="16" />

                    </Grid>

                </lp:LoadingPanel.LoadingContent>

            </lp:LoadingPanel>

            <Button Content="Load Data" x:Name="buttonLoadData" Grid.Row="1" />

        </Grid>

    </Grid>

</UserControl>

Note the two attached properties: Content (inherited from ContentControl) and LoadingContent which is a dependency property I added. You should put the data control in the Content tag and the 'waiting' screen in the LoadingContent tag.

The thing that makes this technique very simple to use is being able to databind the IsLoading property. It becomes very simple to flick the IsLoading property from true to false in your presenter and know that the UI side of things is taken care of.

And finally, the code-behind:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Media.Animation;

using System.ComponentModel;

namespace LoadingPanelSL

{

    public partial class Page : UserControl

    {

        public Page()

        {

            InitializeComponent();

            this.DataContext = new MyDataContext(this);

        }

    }

    public class MyDataContext : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;

        private readonly UserControl view;

        public MyDataContext(UserControl view)

        {

            this.view = view;

            MyDataService service = new MyDataService();

            service.DataLoaded += (object s, MyDataEventArgs e) =>

                {

                    IsLoading = false;

                    MyData = e.Data;

                };

            Button b = view.FindName("buttonLoadData") as Button;

            b.Click += (s, e) =>

                {

                    IsLoading = true;

                    service.GetData();

                };

        }

        private IEnumerable<string> myData;

        public IEnumerable<string> MyData

        {

            get { return myData; }

            set { myData = value; NotifyChange("MyData"); }

        }

        private bool isLoading = false;

        public bool IsLoading

        {

            get { return isLoading; }

            set { isLoading = value; NotifyChange("IsLoading"); }

        }

        private void NotifyChange(string name)

        {

            if (PropertyChanged != null)

            {

                PropertyChanged(this, new PropertyChangedEventArgs(name));

            }

        }

    }

    public class MyDataService

    {

        public event EventHandler<MyDataEventArgs> DataLoaded;

        private string[] str = ("Microsoft Silverlight extends your existing " +

            "development skills empowering you to build new types of applications " +

            "for the Web regardless of target platform or browser Rapidly create " +

            "compelling rich Web applications using all the familiar features " +

            "languages and tools of the .NET framework").Split();

        public void GetData()

        {

            Random rand = new Random();

            Storyboard sb = new Storyboard();

            sb.Duration = new Duration(TimeSpan.FromSeconds(3));

            sb.Completed += new EventHandler((s, e) =>

                {

                    OnDataLoaded(new MyDataEventArgs(from st in str orderby rand.Next() select st));

                });

            sb.Begin();

        }

        private void OnDataLoaded(MyDataEventArgs e)

        {

            if (DataLoaded != null) DataLoaded(this, e);

        }

    }

    public class MyDataEventArgs : EventArgs

    {

        public IEnumerable<string> Data { get; set; }

        public MyDataEventArgs(IEnumerable<string> data)

        {

            Data = data;

        }

    }

}

There's a bit of junk code here to generate 'random' data and simulate an asynchronous request. Nevertheless, the code flow is somewhat similar to the way you find your self working with WCF services in a real LOB app.

If I had time there's any number of improvements I'd make to this, but what sort of software developer has time?  This is exactly the sort of quick and dirty solution that makes Silverlight so fun to work with.

Here's the code.