The Problem Solver : WPF

Rehosting the Workflow Designer in WF4

Maurice — Wed, 23 Dec 2009 16:46:22 GMT

Note: This blog post is written using the .NET framework 4.0 Beta 2

With Windows Workflow Foundation 3 it was possible to rehost the workflow designer in your own application. But possible is about all there was to say about it as it was pretty hard to do anything beyond the basics.

With Windows Workflow Foundation 4 live has become much better on the rehosting front In fact it is possible to create the fully functional and useful workflow editor below in about 200 lines of code. Now that is more like it!

The WorkflowDesigner

The WorkflowDesigner is the main class to work with. This exposes the actual design surface through the View property and the linked property sheet through the PropertyInspectorView property. Both these properties point to ready to use WPF UIElement’s so, as long as the host used WPF, adding them to a form is easy. And loading or saving a workflow is easy to, all it takes is a Load() and Save() function pointing to a XAML file. The code that does this part is below:

_workflowDesigner = new WorkflowDesigner();

_workflowDesigner.Load(_fileName);

var view = _workflowDesigner.View;

Grid.SetColumn(view, 1);

Grid.SetRow(view, 1);

LayoutGrid.Children.Add(view);

var propInspector = _workflowDesigner.PropertyInspectorView;

Grid.SetColumn(propInspector, 2);

Grid.SetRow(propInspector, 1);

LayoutGrid.Children.Add(propInspector);

DesignerMetadata

One thing that is needed is to register the workflow activity designer metadata. It is just a single call but leaving it out means all activities are just a small collapsed shape and won’t expand.

new DesignerMetadata().Register();

Displaying the toolbox with activities

The toolbox on the left if another standard WPF control called the ToolboxControl. Again easy to add to any WPF form. Add to it ToolboxItemWrapper with the activity type to add and you are good to go. Dragging controls onto the design surface just works, no extra work required. In the code below I just scan through all types in a few assemblies and if they are valid activities I add them to the toolbox. Again nice and easy.

var toolbox = new ToolboxControl();

var cat = new ToolboxCategory("Standard Activities");

var assemblies = new List<Assembly>();

assemblies.Add(typeof(Send).Assembly);

assemblies.Add(typeof(Delay).Assembly);

assemblies.Add(typeof(ReceiveAndSendReplyFactory).Assembly);

var query = from asm in assemblies

            from type in asm.GetTypes()

            where type.IsPublic &&

            !type.IsNested &&

            !type.IsAbstract &&

            !type.ContainsGenericParameters &&

            (typeof(Activity).IsAssignableFrom(type) ||

            typeof(IActivityTemplateFactory).IsAssignableFrom(type))

            orderby type.Name

            select new ToolboxItemWrapper(type);

query.ToList().ForEach(ti => cat.Add(ti));

toolbox.Categories.Add(cat);

Grid.SetColumn(toolbox, 0);

Grid.SetRow(toolbox, 1);

LayoutGrid.Children.Add(toolbox);

The current selection

At the top of the form I display the currently selected activity and its parents. The WorkflowDesigner has an Items collection with a bunch of useful objects in there. One of these is a Selection object. We could periodically check this Selection but its even easier to subscribe to chances using the Subscribe() function and passing in a handler that is called whenever the selection changes. Setting up the subscription is another one-liner.

_workflowDesigner.Context.Items.Subscribe<Selection>(SelectionChanged);

The handler itself isn’t very complex either.

private void SelectionChanged(Selection selection)

    var modelItem = selection.PrimarySelection;

    var sb = new StringBuilder();

    while (modelItem != null)

        var displayName = modelItem.Properties["DisplayName"];

        if (displayName != null)

            if (sb.Length > 0)

                sb.Insert(0, " - ");

            sb.Insert(0, displayName.ComputedValue);

        modelItem = modelItem.Parent;

    CurrentActivityName.Text = sb.ToString();

Validating the workflow

It would be nice to let the user know if the workflow is valid. Again quite easy to do by adding a IValidationErrorService to the WorkflowDesigner services collection. In this case I added a listbox to the form and let the IValidationErrorService add each error to the ListBox items. No need to call anything, the IValidationErrorService is automatically called as soon as anything in the workflow changes.

var validationErrorService = new ValidationErrorService(WorkflowErrors.Items);

_workflowDesigner.Context.Services.Publish<IValidationErrorService>(validationErrorService);

The IValidationErrorService consists of a single function that gets the list of errors as a parameter.

public class ValidationErrorService : IValidationErrorService

    private IList _errorList;

    public ValidationErrorService(IList errorList)

        _errorList = errorList;

    public void ShowValidationErrors(IList<ValidationErrorInfo> errors)

        _errorList.Clear();

        foreach (var error in errors)

            _errorList.Add(error.Message);

Running the workflow

Just to be able to run the workflow I added a bit of code that uses a WorkflowApplication to run the workflow. Loading it is also easy, just call the ActivityXamlServices.Load() passing in the file and it will return a DynamicActivity ready to run.

var writer = new StringWriter();

var workflow = ActivityXamlServices.Load(_fileName);

var wa = new WorkflowApplication(workflow);

wa.Extensions.Add(writer);

wa.Completed = WorkflowCompleted;

wa.OnUnhandledException = WorkflowUnhandledException;

wa.Run();

So all together I have a working application that I can use to edit and run workflows. So who still needs Visual Studio 2010?

Sweet

Download CustomWorkflowDesigner.zip

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Nederlandse CodeCamp 2009

Maurice — Mon, 19 Oct 2009 10:26:00 GMT

Op 21 november 2009 organiseren de SDN, Stichting dotNed en VBcentral samen het derde Nederlandse Code Camp. Dit is een dag lang met code, code sharing, freaking en gezellig samenzijn. Een evenement door ontwikkelaars, voor ontwikkelaars. De regie ligt voor een belangrijk deel bij de deelnemers! Het aantal plaatsen voor deelnemers is wel beperkt tot maximaal 150. Wacht dus niet te lang met beslissen want voor je het weet is er geen plaats meer. Vergeet bij je aanmelding niet op te geven welke onderwerpen je interesse hebben. Bovendien nodigen we iedereen graag uit om zelf een sessie in te vullen.

Op de website, www.codecamp.nl, vind je meer informatie en kan je je aanmelden.

Using Model – View – ViewModel with Silverlight

Maurice — Tue, 07 Apr 2009 14:23:46 GMT

The View – Model – ViewModel design pattern, also known as MVVM, is getting more popular these days. I have found it extremely easy to use when developing very different applications and have used the design pattern recently in both ASP.NET, WPF and Silverlight applications. However easy as it might be is seems to confuse people as I have seen some terrible examples where people make a complete mess of things.

Josh Smith did an excellent screen cast for Pixel8 on using MVVM with WPF, you can find it here.

Even thought the UI technology used doesn't change the basic MVVM pattern there are some subtle differences, like not easily being able to use ICommand in Silverlight, so I decided to create a small Silverlight sample.

The basic structure goes like this:

The user interacts with a View, implemented as a Silverlight user control.
The View is data bound to a ViewModel. This is the most important step to remember. The ViewModel is just another class.
The ViewModel is a wrapper for a Model. Think of the Model as the data and the business rules.

The Model

The Model I am using is very simple and has two read-write properties, FirstName and LastName, and a single read-only property, FullName. The FullName property represents some business rule on how a name should be formatted. I know it is a bit of a lame business rule but it is just a sample . The Model also implements INotifyPropertyChanged so the UI can be updated whenever a value is updated. The complete model looks like this:

        1: using System.ComponentModel;

       2:  

       3: namespace SilverlightMVVMDemo.Model

       4: {

       5:     public class Customer : INotifyPropertyChanged

       6:     {

       7:         private string _firstName;

       8:         private string _lastName;

       9:  

        public string FirstName

        {

            get { return _firstName; }

            set

            {

                _firstName = value;

                OnPropertyChanged("FirstName");

                OnPropertyChanged("FullName");

            }

        }

        public string LastName

        {

            get { return _lastName; }

            set

            {

                _lastName = value;

                OnPropertyChanged("LastName");

                OnPropertyChanged("FullName");

            }

        }

  

  

        public string FullName

        {

            get { return FirstName + " " + LastName; }

        }

  

        public event PropertyChangedEventHandler PropertyChanged;

  

        protected void OnPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

            {

                var args = new PropertyChangedEventArgs(propertyName);

                PropertyChanged(this, args);

            }

        }

    }

}

The View

The View is just a Silverlight user control that makes things visible for the user. All controls use data binding to get to their values. There is one interesting twist here. Just like I had a business rule about how to format a FullName I have a rule about the font weight to use to display the FullName. This is just UI so not a business rule and as a result it is not stored in the Model. We do not want to code this in the UI as that makes things hard to test. So that leaves one place, the ViewModel . And the View uses data binding to set the FontWeight property.

The complete View looks like this:

       1: <UserControl

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

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

       4:     xmlns:SilverlightMVVMDemo_ViewModel="clr-namespace:SilverlightMVVMDemo.ViewModel" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" x:Class="SilverlightMVVMDemo.View.CustomerView" 

       5:     Width="400" Height="300" mc:Ignorable="d">

       6:     <Grid x:Name="LayoutRoot" 

       7:           Background="White">

       8:         <Grid.RowDefinitions>

       9:             <RowDefinition Height="0.133*"/>

            <RowDefinition Height="0.133*"/>

            <RowDefinition Height="0.133*"/>

            <RowDefinition Height="0.18*"/>

            <RowDefinition Height="0.42*"/>

        </Grid.RowDefinitions>

        <Grid.ColumnDefinitions>

            <ColumnDefinition Width="0.3*"/>

            <ColumnDefinition Width="0.7*"/>

        </Grid.ColumnDefinitions>

        <TextBlock Text="Firstname:" 

                   Margin="8"/>

        <TextBox Text="{Binding Path=FirstName, Mode=TwoWay}" 

                 Grid.Column="1" 

                 Margin="8,8,8,8"/>

        <TextBlock Text="Lastname:" 

                   Grid.Row="1" 

                   Margin="8"/>

        <TextBox Text="{Binding Path=LastName, Mode=TwoWay}" 

                 Grid.Row="1" 

                 Grid.Column="1" 

                 Margin="8,8,8,8"/>

        <TextBlock Text="Fullname:" 

                   Grid.Row="2" 

                   Margin="8"/>

        <TextBox Text="{Binding Path=FullName}" 

                 Grid.Row="2" 

                 Grid.Column="1" 

                 Margin="8,8,8,8"

                 FontWeight="{Binding Path=FullNameFontWeight}"

                 IsReadOnly="True"/>

        <Button Content="Save"

                Click="Button_Click"

                Grid.Row="3" 

                Grid.Column="1" />

    </Grid>

</UserControl>

The code behind is very simple and looks like this:

       1: using System.Windows.Controls;

       2: using SilverlightMVVMDemo.ViewModel;

       3:  

       4: namespace SilverlightMVVMDemo.View

       5: {

       6:     public partial class CustomerView : UserControl

       7:     {

       8:         public CustomerView()

       9:         {

      10:             InitializeComponent();

      11:             DataContext = new CustomerViewModel();

      12:         }

      13:  

      14:         private void Button_Click(object sender, System.Windows.RoutedEventArgs e)

      15:         {

      16:             var viewModel = (CustomerViewModel)DataContext;

      17:             viewModel.Save();

      18:         }

      19:     }

      20: }

In an ideal world there would be no code at all, or only that setting the DataContext but as Silverlight makes it a little harder to use commands there is a single line, okay two counting the cast, to pass the save command on to the ViewModel.

The ViewModel

The ViewModel class is the one that glues the View and the Model together, hence its name . basically the ViewModel wraps each Model object, so if you want to use a collection of customer models you create a collection of CustomerViewModel objects and databind against them. The ViewModel catches all PropertyChanged events from the Model and passes them on to the user interface. Whenever the FullName property changes the FullNameFontWeight might also change so in that case an extra PropertyChanged event is raised. Note that calculation of the FontWeight to use is part of the ViewModel as the UI depends on this but it is not a business rule per se.

Another example of a property like this would be the CSS class to use in an ASP.NET application. basically if a UI property changes, create a property get to do so and databind it.

The complete ViewModel class looks like this:

       1: using System.ComponentModel;

       2: using System.Windows;

       3: using SilverlightMVVMDemo.Model;

       4:  

       5: namespace SilverlightMVVMDemo.ViewModel

       6: {

       7:     public class CustomerViewModel : INotifyPropertyChanged

       8:     {

       9:         private Customer _model;

  

        public CustomerViewModel()

        {

            Model = new Customer() { FirstName = "Maurice", LastName = "de Beijer" };

        }

  

        public CustomerViewModel(Customer model)

        {

            Model = model;

        }

  

  

        public Customer Model

        {

            get { return _model; }

            private set

            {

                if (_model != null)

                    _model.PropertyChanged -= ModelPropertyChanged;

  

                _model = value;

  

                if (_model != null)

                    _model.PropertyChanged += ModelPropertyChanged;

            }

        }

  

        void ModelPropertyChanged(object sender, PropertyChangedEventArgs e)

        {

            OnPropertyChanged(e.PropertyName);

  

            if (e.PropertyName == "FullName")

                OnPropertyChanged("FullNameFontWeight");

        }

  

  

        public string FirstName

        {

            get { return Model.FirstName; }

            set { Model.FirstName = value; }

        }

        public string LastName

        {

            get { return Model.LastName; }

            set { Model.LastName = value; }

        }

  

        public string FullName

        {

            get { return Model.FullName; }

        }

  

        public FontWeight FullNameFontWeight

        {

            get

            {

                if (FullName.Length > 20)

                    return FontWeights.ExtraBold;

                else if (FullName.Length > 15)

                    return FontWeights.Bold;

                else if (FullName.Length > 10)

                    return FontWeights.Normal;

                else

                    return FontWeights.Light;

            }

        }

  

        public event PropertyChangedEventHandler PropertyChanged;

  

        protected void OnPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

            {

                var args = new PropertyChangedEventArgs(propertyName);

                PropertyChanged(this, args);

            }

        }

  

        internal void Save()

        {

            // Implement the logic to save the customer.

        }

    }

}

In this case I duplicated all properties from the Model in the ViewModel. This is not a must, some people prefer to expose and bind to the Model directly. It saves a few lines of code but I prefer not to do so. Of course there is no need to duplicate properties the UI is never going to bind to directly.

Model-View-ViewModel guidelines

Not very difficult at all as long as you keep to a few guidelines:

Never set any UI properties from your CS code with the exception of the DataContext.
If you need an event handler in your code behind, like the button click, make it a single line and pass the request onto the ViewModel.
All UI control properties that need to change at runtime do so by data binding to a ViewModel property.
Organize your ViewModel types per View and not per Model. It is perfectly fine to create a ViewModel that wraps two different Models. A View has only a single DataContext so you cannot bind it to multiple ViewModel objects.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Surface at the last Software Developer Event

Maurice — Mon, 06 Apr 2009 07:27:04 GMT

As was to be expected the Surface machine at the last SDE was a big success and with lots of people wanting to have a go at it.

Nice to see the interest. And I am grateful Martin Tirion from the Dutch Microsoft office let us borrow the machine for a day.

At the end of June we will have the next big event

Cu there.

BTW you can find more pictures from the event here.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Want to download all MIX sessions?

Maurice — Tue, 31 Mar 2009 06:52:40 GMT

Then you should check Mike Swanson’s blog post here. He has two batch files, the first downloads all MIX session recordings with in the format you like, the second renames them so it is easier to make sense of all the media file names.

If you just want a list of all sessions with download links this page might be the thing for you.

So much better than downloading them by hand. Not as good as going to the MIX itself but if you, like me, couldn’t go it is still a nice way to see all the content.

Enjoy!

Visual Basic QuickStarts and How-to Topics for the Composite Application Guidance for WPF and Silverlight

Maurice — Wed, 25 Mar 2009 08:12:57 GMT

The P&P team have just release a VB version of the Prism quick starts.

You can download the goods here.

Enjoy!

Software Development Event march 30th

Maurice — Mon, 23 Mar 2009 15:40:29 GMT

Just one week to go to the next Software Development Event. The schedule with all the sessions is looking good. But this time there is even more!

We will have a Microsoft Surface machine somewhere in the common area for people to try our. And if you have never played, oops tested, with a Surface machine before this is a truly exiting machine!

Just goes to show, the SDN will go to extraordinary efforts to please all attendees

You can see the full schedule here. And don’t forget, we are not in Ede this time but in a great new location in Driebergen.

Hope to see everyone there next week Monday.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Looking back at the MVP Summit

Maurice — Sat, 07 Mar 2009 11:08:09 GMT

Last week lots of MVP, myself included, where in Redmond visiting Microsoft on our yearly MVP pilgrimage. The MVP Summit is always a great event. Not only do we get to talk to the MS team members who actually design and build all the software we love and use but we also get to meet each other. And with MVP’s being located around the world that is kind of rare as well.

Despite this being a great event I still have very mixed feelings about this last MVP summit. The problem isn’t the events itself or the people I met, that was al great . No the problem was in some of the technological decisions made in product groups. Unfortunately I can’t divulge details yet because I have signed an NDA but as soon .NET 4.0 as beta 1 is made public I will be able to blog about some of these decisions. And rest assured I will!

The reason we really need to is the way these important changes are communicated. Or should I say not communicated. Some very important changes where not communicated at all and could only be derived by bullet points missing from PowerPoint slides. Only when directly asked about the missing bullet point would someone say “Yes that is right, we decided to …. NDA … because … NDA …”. Sorry about the NDA part .

I can only say that these decisions are a big problem and I know several MVP’s who decided to skip other sessions on the same product as a result. I didn’t, as far as I am concerned ignoring a problem is not going to make it go away, but I really think this product team needs to reevaluate this decision and the general future trend.

Despite this hiccup I am very exited about lots of the things I got to see and am really looking forward to .NET 4 and Visual Studio 2010. Now if we only could have a beta today . When we will have a first beta is still a big question though. If a date was announced I missed it, the best I heard was a quarter and is quite a time span.

Enjoy.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Presenting at VB Central

Maurice — Tue, 03 Mar 2009 13:46:17 GMT

Next week, on march 10th, I will be doing a presentation on getting started with WCF at the VB Central user group in the Netherlands. Its a free event so if you are in the neighborhood feel free to drop by. They do ask you register beforehand. Besides my session on WCF there will also be a session on using WPF and data binding.

Mode details and the registration page can be found here.

Hope to see you there.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Patterns & Practices release Prism version 2

Maurice — Wed, 18 Feb 2009 19:01:01 GMT

The Patterns & Practices group at Microsoft have just released Prism version 2. I am pretty exited about this because Prism version 2 supports both WPF and Silverlight. And as it makes extensive use of the Model - View - ViewModel amongst other design patterns it is a great place to learn, even if you don't use it as is.

Check out the main "Composite Application Guidance for WPF and Silverlight" page here. Or read Blaine Wastell about it here.

Enjoy!

Data validation - Silverlight versus WPF part 2

Maurice — Tue, 30 Dec 2008 16:04:52 GMT

In a previous blog post I pointed out that quite a difference between data validation between Silverlight and WFP. As I don’t think adding data validation in the UI is a good thing I focused on validation in the business object by throwing an exception when the value was not acceptable. As Beth pointed out WPF also supports the IDataErrorInfo interface as she demonstrates here.

I think using the IDataErrorInfo interface is superior to throwing exceptions. After all exceptions should be exceptional and users entering invalid data in real applications is not very exceptional . However Silverlight only contains a subset of the .NET framework and doesn’t include the IDataErrorInfo interface.

So using the IDataErrorInfo in Silverlight will option will not work right?

Wrong, it is a very simple interface and we can just add it ourselves. We can even add it using the same namespace System.ComponentModel to when the interface gets added to Silverlight we can just remove our copy .

So this is my Silverlight implementation of the IDataErrorInfo interface:

namespace System.ComponentModel
{
    // Summary:
    //     Provides the functionality to offer custom error information that a user
    //     interface can bind to.
    public interface IDataErrorInfo
    {
        // Summary:
        //     Gets an error message indicating what is wrong with this object.
        //
        // Returns:
        //     An error message indicating what is wrong with this object. The default is
        //     an empty string ("").
        string Error { get; }

        // Summary:
        //     Gets the error message for the property with the given name.
        //
        // Parameters:
        //   columnName:
        //     The name of the property whose error message to get.
        //
        // Returns:
        //     The error message for the property. The default is an empty string ("").
        string this[string columnName] { get; }
    }
}

I just copied this code by right clicking the IDataErrorInfo in my WPF application and selecting all the code shown.

So how do WPF and Silverlight compare when using the IDataErrorInfo interface?

The sample business object is the same person as in the pervious blog post. Only this time I did implement both the IDataErrorInfo and the INotifyPropertyChanged interface. The INotifyPropertyChanged is not really needed in WPF here, it will work just as well without it, but is a good practice to do every time.

public class Person : IDataErrorInfo, INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            _firstName = value;
            if (string.IsNullOrEmpty(_firstName))
                _errors["FirstName"] = "The first name cannot be empty.";
            else
                _errors["FirstName"] = null;
            OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            _lastName = value;
            if (string.IsNullOrEmpty(_lastName))
                _errors["LastName"] = "The last name cannot be empty.";
            else
                _errors["LastName"] = null;
            OnPropertyChanged("LastName");
        }
    }

    private Dictionary<string, string> _errors = new Dictionary<string, string>();
    public string Error
    {
        get
        {
            StringBuilder sb = new StringBuilder();
            foreach (var item in _errors)
                if (item.Value != null)
                    sb.AppendLine(item.Value);

            return sb.ToString();
        }
    }

    public string this[string columnName]
    {
        get
        {
            string result = null;
            _errors.TryGetValue(columnName, out result);

            return result;
        }
    }

    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    public event PropertyChangedEventHandler PropertyChanged;

The WPF application

The XAML in the WPF application is simple, even simpler as previous blog post and looks like this:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="150"/>
        <ColumnDefinition />
        <ColumnDefinition />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>
    <TextBlock Text="Firstname:" Grid.Row="0" Grid.Column="0"/>
    <TextBox Text="{Binding FirstName, ValidatesOnDataErrors=True}" 
             Grid.Row="0" Grid.Column="1"/>
    <TextBlock Text="Lastname:" 
               Grid.Row="1" Grid.Column="0"/>
    <TextBox Text="{Binding LastName, ValidatesOnDataErrors=True}" 
             Grid.Row="1" Grid.Column="1"/>
    <Button Content="Close" Grid.Row="2" Grid.Column="0"/>
</Grid>

Nice, no longer do we need to add the ValidationRules collection and add the ExceptionValidationRule to it, instead all we have to do it set the ValidatesOnDataErrors to true. Much nicer .

How about the Silverlight application?

The Silverlight XAML isn’t much more complicated and looks like this:

<Grid x:Name="LayoutRoot" Background="White">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="150"/>
        <ColumnDefinition />
        <ColumnDefinition  Width="20"/>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>
    <TextBlock Text="Firstname:" Grid.Row="0" Grid.Column="0"/>
    <TextBox Text="{Binding FirstName, Mode=TwoWay}" 
             Grid.Row="0" Grid.Column="1"/>
    <local:ErrorStatus PropertyName="FirstName"  Grid.Row="0" Grid.Column="2"/>
    <TextBlock Text="Lastname:" Grid.Row="1" Grid.Column="0"/>
    <TextBox Text="{Binding LastName, Mode=TwoWay}" 
             Grid.Row="1" Grid.Column="1"/>
    <local:ErrorStatus PropertyName="LastName" Grid.Row="1" Grid.Column="2"/>
    <Button Content="Close" Grid.Row="2" Grid.Column="0" Click="Button_Click" />
</Grid>

The main difference is the addition of two local:ErrorStatus elements. Most of the extra complexity is in this control which is needed because Silverlight has no default way to display validation errors. Please note that there is no longer a BindingValidationError handler involved, everything the app needs is done in XAML, much better than the approach when throwing exceptions. Also note that all I need to do is set the PropertyName attribute to indicate which property validation to display. When run this page looks like this:

The ErrorStatus control

All “magic” happens inside of the ErrorStatus control. This is a real simple user control. Now if I wanted to create a reusable control I would need to put some more work into it and use the VisualStateManager with the States&Parts model but this simple control is enough to demonstrate the solution.

The ErrorStatus.xaml looks like this:

<UserControl x:Class="SilverlightApplication5.ErrorStatus"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="16" Height="16">
    <Grid x:Name="LayoutRoot" >
        <Ellipse Fill="Red"/>
        <TextBlock Foreground="White" 
                   HorizontalAlignment="Center" 
                   VerticalAlignment="Stretch" 
                   FontWeight="Bold" >!</TextBlock>
    </Grid>
</UserControl>

Real simple, just a red circle with a white exclamation mark in it.

The code is not very complex either. Most of it is related to either checking if the DataContext changed, see this post for an explanation, and when a property value has changed.

public partial class ErrorStatus : UserControl
{
    public ErrorStatus()
    {
        InitializeComponent();
        SetBinding(MyDataContextProperty, new Binding());
    }

    public static readonly DependencyProperty MyDataContextProperty =
        DependencyProperty.Register("MyDataContext", 
                                    typeof(object), 
                                    typeof(ErrorStatus), 
                                    new PropertyMetadata(DataContextChanged));

    public static readonly DependencyProperty PropertyNameProperty =
        DependencyProperty.Register("PropertyName",
                                    typeof(string),
                                    typeof(ErrorStatus),
                                    null);

    private static void DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
    {
        INotifyPropertyChanged person;
        ErrorStatus errorStatus = (ErrorStatus)sender;

        person = e.OldValue as INotifyPropertyChanged;
        if (person != null)
            person.PropertyChanged -= errorStatus.person_PropertyChanged;

        person = e.NewValue as INotifyPropertyChanged;
        if (person != null)
            person.PropertyChanged += errorStatus.person_PropertyChanged;

        errorStatus.UpdateStatus(e.NewValue);
    }

    public string PropertyName
    {
        get { return (string)GetValue(PropertyNameProperty); }
        set { SetValue(PropertyNameProperty, value); }
    }

    private void person_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == PropertyName)
            UpdateStatus(sender);
    }

    private void UpdateStatus(object sender)
    {
        IDataErrorInfo person = sender as IDataErrorInfo;
        if (person != null)
        {
            string errorText = person[PropertyName];
            if (string.IsNullOrEmpty(errorText))
                Opacity = 0;
            else
                Opacity = 100;

            ToolTipService.SetToolTip(this, errorText);
        }
    }
}

The real work happens in the UpdateStatus() function right at the bottom. This function is called every time the target property changes or the DataContext is set. Basically it checks if there are any errors and makes the control visible or invisible depending on the result. Besides the control’s visibility it also sets the tooltip text to the error. The only other thing worth mentioning is that I make the control invisible by using the Opacity instead of the Visibility property. The reason is that I do not want to change the layout of the controls on the page just because the validation status changed. WPF has a Visibility option of Visibility.Hidden but unfortunately Silverlight doesn’t support this. Not a big problem as making a control transparent is just a good in this case.

Conclusion

Using the IDataErrorInfo is a much nicer approach and creating just one, pretty simple, control in Silverlight makes it work just as easy in Silverlight as WPF. So much better than throwing exceptions

Download the source

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

How to know when the DataContext changed in your control

Maurice — Mon, 29 Dec 2008 13:52:23 GMT

The DataContext is a wonderful property, you can set it somewhere in the logical tree and any child control can just bind to properties without having to know where the DataContext was set. A great capability that makes live much simpler when writing XAML. But sometimes when building a control of some sorts you just need to know when the DataContext has changed. For example when binding to events on whatever object is set as the current DataContext.

Take for example the following simple form.

In this form I am data bound to a real simple Person object which implements the INotifyPropertyChanged interface so we can be informed that a property has changed. The bottom control is a very simple custom control that displays the last property being changed. The code looks like this:

public partial class MyControl : UserControl
{
    public MyControl()
    {
        InitializeComponent();
        Loaded += new RoutedEventHandler(MyControl_Loaded);
    }

    void MyControl_Loaded(object sender, RoutedEventArgs e)
    {
        INotifyPropertyChanged person = DataContext as INotifyPropertyChanged;
        if (person != null)
            person.PropertyChanged += new PropertyChangedEventHandler(person_PropertyChanged);
    }

    void person_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        PropertyName.Text = e.PropertyName;
    }
}

The Page code looks like this:

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();
        DataContext = new Person() { FirstName = "Maurice", LastName = "de Beijer" };
    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        DataContext = new Person() { FirstName = "John", LastName = "Doe" };
    }
}

Pretty simple and it works just fine as long as I don’t press the button.

Pressing the button means I set the DataContext to a new person object. The data binding notices and shows the required changes just fine. However the INotifyPropertyChanged event is still hooked on the old person object and we somehow need to unhook this object and hook the new person object.

In WPF there is an DataContextChanged event that will let us know the DataContext is changed and we need to change out event binding. Unfortunately Silverlight the FrameworkElement class in Silverlight has the same event but it is marked as internal so we cannot use it .

So how can we know the DataContext has changed is the event is not public?

It turns out the standard DataBinding holds the answer to the problem. All we need to do is create an extra DependencyProperty and bind that to the DataContext. Sounds complicated but is actually quite simple.

The new version of my custom control is below.

public partial class MyControl : UserControl
{
    public MyControl()
    {
        InitializeComponent();
        SetBinding(MyDataContextProperty, new Binding());
    }


    public static readonly DependencyProperty MyDataContextProperty =
        DependencyProperty.Register("MyDataContext",
                                    typeof(Object),
                                    typeof(MyControl),
                                    new PropertyMetadata(DataContextChanged));

    private static void DataContextChanged(
        object sender, 
        DependencyPropertyChangedEventArgs e)
    {
        MyControl myControl = (MyControl)sender;
        INotifyPropertyChanged person = e.NewValue as INotifyPropertyChanged;
        if (person != null)
            person.PropertyChanged += myControl.person_PropertyChanged;
    }

    void person_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        PropertyName.Text = e.PropertyName;
    }
}

Instead of just reading the DataContext property I first created a new DependencyProperty called MyDataContextProperty. The reason this exists is so we can set the PropertyChangedCallback that lets us know when the property is changed. Note there are no normal property get and set methods as we don’t need them. The remaining and most important part to this to work is the line:

SetBinding(MyDataContextProperty, new Binding());

This line in the constructor actually bind the value of the MyDataContext to the real DataContext property.

With this set up I am free to do whatever I want in the DataContextChanged event that gets fired whenever the DataContext changes. In this example the code just removes the vent handler for the old DataContext PropertyChanged event and adds an event hook on the PropertyChanged event for the new DataContext.

private static void DataContextChanged(
    object sender,
    DependencyPropertyChangedEventArgs e)
{
    MyControl myControl = (MyControl)sender;
    INotifyPropertyChanged person;

    person = e.OldValue as INotifyPropertyChanged;
    if (person != null)
        person.PropertyChanged -= myControl.person_PropertyChanged;

    person = e.NewValue as INotifyPropertyChanged;
    if (person != null)
        person.PropertyChanged += myControl.person_PropertyChanged;
}

So all it takes is a few lines of code and we know exactly when the DataContext was changed .

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Data validation - Silverlight versus WPF

Maurice — Wed, 24 Dec 2008 14:00:34 GMT

When I am creating business applications validating the data in business objects, and displaying any errors, is always a big deal. Even though WPF and Silverlight both use XAML and support data binding the default way to display errors is quite different. Now I am focusing on validation in the business object here even though WPF has additional capabilities of validating input in the XAML using ValidationRules. While there might be some good reason to validate data directly in the UI in some cases I find it a requirement to validate data inside a business object so the validation is done regardless of the way the business object is configured.

Both with Silverlight and WPF it is possible to create business objects that validate their properties. Unfortunately the normal way to do this is by throwing an exception in the property setter if the validation fails. Now I don't really like this approach, in fact I prefer the approach taken by Rocky Lhotka in CSLA or Paul Stovell in his article about Delegates and Business Objects. But that is a subject for another post, lets first take a look at the out of the box behavior.

The test "business object" I am working with is real simple. In fact so simple that I don't even implement INotifyPropertyChanged, something I recommend you always do. But for the purposes of validation it serves no useful purpose so I left it out. The Person class, used both in WPF and Silverlight looks like this:

public class Person
{
    public string FirstName { get; set; }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            _lastName = value;
            if (string.IsNullOrEmpty(_lastName))
                throw new ArgumentNullException();
        }
    }
}

Pretty simple right, the "business rule" here is that the LastName property cannot be empty.

Validation in WPF

The XAML used in the WPF sample looks like this:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="200" Width="400" >
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="150"/>
            <ColumnDefinition />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
        </Grid.RowDefinitions>
        <TextBlock Text="Firstname:" Grid.Row="0" Grid.Column="0"/>
        <TextBox Text="{Binding FirstName}" Grid.Row="0" Grid.Column="1"/>
        <TextBlock Text="Lastname:" Grid.Row="1" Grid.Column="0"/>
        <TextBox Grid.Row="1" Grid.Column="1">
            <TextBox.Text>
                <Binding Path="LastName">
                    <Binding.ValidationRules>
                        <ExceptionValidationRule/>
                    </Binding.ValidationRules>
                </Binding>                
            </TextBox.Text>
        </TextBox>
        <Button Content="Close" Grid.Row="2" Grid.Column="0"/>
    </Grid>
</Window>

Not very complex but as we can see there is quite a difference between the FirstName TextBox with no validation and the LastName TextBox which must handle the not empty validation. In order for the UI to know about the validation we need to add the Binding.ValidationRules element and add to that the ExceptionValidationRule. The ExceptionValidationRule basically says that any exception raised during the property setter is a failed validation rule. Not very complicated but it does add quite a bit of XAML just to be able to display the fact that something is wrong. When we run the code and empty the LastName TextBox the result looks like this:

The red line around the TextBox indicates that there is some kind of error. Where does the red box come from? Well that is just the default ErrorTemplate used and you are free to change it by setting the Validation.ErrorTemplate property on the TextBox.

Validation in Silverlight

The XAML in Silverlight looks somewhat different. The main XAML is pretty much the same but as soon as we get into data binding things look very different. See for yourself:

<UserControl x:Class="SilverlightApplication1.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="150"/>
            <ColumnDefinition />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
        </Grid.RowDefinitions>
        <TextBlock Text="Firstname:" Grid.Row="0" Grid.Column="0"/>
        <TextBox Text="{Binding FirstName}" Grid.Row="0" Grid.Column="1"/>
        <TextBlock Text="Lastname:" Grid.Row="1" Grid.Column="0"/>
        <TextBox Grid.Row="1" Grid.Column="1">
            <TextBox.Text>
                <Binding Path="LastName" Mode="TwoWay" 
                         NotifyOnValidationError="True" 
                         ValidatesOnExceptions="True" />
            </TextBox.Text>
        </TextBox>
        <Button Content="Close" Grid.Row="2" Grid.Column="0"/>
    </Grid>
</UserControl>

This time we need to set the NotifyOnValidationError and ValidatesOnExceptions properties of the binding to true. In WPF these properties don't exist and we used the ValidationRules and ExceptionValidationRule to reach the same effect. So what happens when we run this and clear out the LastName TextBox? Actually the validation fails, the exception is thrown and we don't see anything at all . The reason is that in Silverlight there is no Validation.ErrorTemplate, instead we have to do something to let the user know an error occurred. In order to do so we need to subscribe to the BindingValidationError event that fires as soon as a validation fails. To achieve a similar effect as the WPF application we could use some code like this:

public Page()
{
    InitializeComponent();
    BindingValidationError += new EventHandler<ValidationErrorEventArgs>(Page_BindingValidationError);
}

private Brush _borderBrush = null;
void Page_BindingValidationError(object sender, ValidationErrorEventArgs e)
{
    Control control = (Control)e.OriginalSource;

    if (_borderBrush == null)
        _borderBrush = control.BorderBrush;

    switch (e.Action)
    {
        case ValidationErrorEventAction.Added:
            control.BorderBrush = new SolidColorBrush(Colors.Red);
            break;
        case ValidationErrorEventAction.Removed:
            control.BorderBrush = _borderBrush;
            break;
        default:
            break;
    }
}

Not very complicated but still we need to do so in code. Of course the BindingValidationError event doesn't exist in WPF either so non of this XAML or code would post from Silverlight back to WPF .

The effect is the same as in WPF however and looks like this:

Conclusion

Validation is quite different in WPF and Silverlight making for non portable XAML and code. However the biggest deal is that validation, at least on the WPF side, is more focused on the UI that the business layer where it should be. And the small part where the validation in the UI is used it is completely focused on exceptions and not in business rules, something far superior. So for any serious business application this subject needs some significant work, just like Rock Lhotka had to do with his CSLA framework.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

WrapPanel in ListBox revisited

Maurice — Mon, 08 Dec 2008 18:11:42 GMT

Last week logged about using a WrapPanel in a listBox and demonstrated how to get the content to wrap around, read about it here.

Turns out the XAML can be even easier. In the previous post I used a ControlTemplate with a Grid to stop the WrapPanel from just expanding horizontally. Turns out there us an even easier way to do so by disabling the horizontal scrollbar using the ListBox ScrollViewer. The following XAML will do the trick just fine:

<UserControl xmlns:controls="clr-namespace:Microsoft.Windows.Controls;assembly=Microsoft.Windows.Controls"  
             x:Class="SilverlightApplication4.Page"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
             Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <ListBox x:Name="DemoList" 
                 ScrollViewer.HorizontalScrollBarVisibility="Disabled">
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <controls:WrapPanel />
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <TextBlock Text="{Binding}" 
                   TextAlignment="Right" 
                   Width="25" />
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>
    </Grid>
</UserControl>

Used in combination with the following code:

using System.Linq;
using System.Windows;
using System.Windows.Controls;

namespace SilverlightApplication4
{
    public partial class Page : UserControl
    {
        public Page()
        {
            InitializeComponent();
            Loaded += new RoutedEventHandler(Page_Loaded);
        }

        void Page_Loaded(object sender, RoutedEventArgs e)
        {
            DemoList.ItemsSource = Enumerable.Range(1, 250);
        }
    }
}

it produces this Silverlight page:

We even get some keyboard support with the new XAML although I am not quite sure if I am happy about that or not. Selecting an element and pressing the down arrow key makes the selection move to the right. Makes sense in that it is the next item in the ItemsSource bit not quite what I was hoping for.

Just for a quick comparison I copied the XAML and code to a WPF application to see what would happen there. Fortunately the only change I hard to make to the ListBox was removing the controls namespace. Great

When I ran the same in WPF I do see the keyboard behavior I would like. Pressing the down arrow selects the next item below the current, the same with up and the other arrow keys and even the page up/down scroll a page but move in the same column. Now this is much better behavior!

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Unit testing in Silverlight part 2

Maurice — Sun, 07 Dec 2008 21:11:23 GMT

Part 1
Part 2
Part 3
Part 4

In my previous post I described the basic setup of unit testing in Silverlight, you can read all about it here.

The basics where very nice but lots of code we write in Silverlight has to do with networking and in Silverlight that means asynchronous code, something that is always hard to test!

Because, just I like using Flickr, lets download some pictures and see what it takes to make that testable. Below is the very simple application we need to unit test, basically a list of pictures from my Flickr photo stream.

Nothing fancy, just a ListBox with pictures

The code in the page is no big deal either and looks like this:

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();
        Loaded += new RoutedEventHandler(Page_Loaded);
    }

    void Page_Loaded(object sender, RoutedEventArgs e)
    {
        PhotoCollection photoCollection = 
            (PhotoCollection)Resources["PhotoCollectionDS"];
        FlickrRequest request = new FlickrRequest();

        request.PhotoSearchByUser("97044050@N00", 
            (photo) => photoCollection.Add(photo));
    }
}

Basically it just retrieves the PhotoCollection, creates a FlickrRequest object and tells it to search for a users photos and add each photo found to the collection. The PhotoCollection is no big deal either and is just a ObservableCollection<Photo>.

The interesting stuff is in the FlickrRequest class. This is the one that needs to be unit tested and looks like this:

public class FlickrRequest
{
    private const string _flickrUrl = "http://api.flickr.com/services/rest";

    public void PhotoSearchByUser(string userId, Action<Photo> action)
    {
        string url = string.Format(
            @"{0}/?method={1}&api_key={2}&user_id={3}&extras=original_format",
            _flickrUrl, "flickr.photos.search", App.FlickrApiKey, userId);

        WebClient client = new WebClient();
        client.OpenReadCompleted += (sender, e) =>
        {
            if (e.Error == null)
            {
                FlickrResponse response = DeserializeResult(e.Result);
                if (response.Status == "ok")
                {
                    foreach (var photo in response.Photos.Photos)
                        action(photo);

                    if (response.Photos.Page < response.Photos.PageCount)
                    {
                        string nextUrl = string.Format("{0}&page={1}", 
                            url, response.Photos.Page + 1);
                        client.OpenReadAsync(new Uri(nextUrl));
                    }
                }
            }
        };

        client.OpenReadAsync(new Uri(url));
    }

    public static FlickrResponse DeserializeResult(Stream stream)
    {
        FlickrResponse response = null;
        try
        {
            XmlSerializer ser = new XmlSerializer(typeof(FlickrResponse));
            response = (FlickrResponse)ser.Deserialize(stream);
        }
        catch (InvalidOperationException)
        {
            response = new FlickrResponse();
        }

        if (response.Photos == null)
            response.Photos = new ResponsePhotoCollection();
        if (response.Photos.Photos == null)
            response.Photos.Photos = new Photo[] { };

        return response;
    }
}

The PhotoSearchByUser function here is the interesting one as it uses the WebClient class and the Flickr REST API to download the photo information. This code also has the complexity that not all the data is returned from the first call but we need to do multiple calls to get all the photo information. Creating a unit test should be straightforward expect for the fact that we do not want to depend on Flickr and fake out the networking parts. After all if we didn’t it would be a integration test instead of a unit test. So we need to somehow fake the networking behavior.

With regular .NET code I use TypeMock to help out with unit testing and I am sure that would make live easy here but unfortunately there is no Silverlight version of TypeMock yet. In fact, as far as I am aware, there is not a single mock framework for use with Silverlight. So we need to do this some other way.

First we need to get rid of the WebClient class because non of its methods are virtual and we cannot substitute another type. So the first thing I did was create a TestableWebClient, which looks just like the original WebClient only it allows me to change the behavior for testing purposes. The TestableWeblient looks like this:

public class TestableWebClient
{
    public event EventHandler<TestableOpenReadCompletedEventArgs> OpenReadCompleted;

    public virtual void OpenReadAsync(Uri address)
    {
        WebClient client = new WebClient();
        client.OpenReadCompleted += (s, e) =>
            {
                OnOpenReadCompleted(e);
            };
        client.OpenReadAsync(address);
    }

    protected void OnOpenReadCompleted(OpenReadCompletedEventArgs e)
    {
        TestableOpenReadCompletedEventArgs args = 
            new TestableOpenReadCompletedEventArgs(e);
        OnOpenReadCompleted(args);
    }

    protected void OnOpenReadCompleted(TestableOpenReadCompletedEventArgs e)
    {
        if (OpenReadCompleted != null)
        {
            OpenReadCompleted(this, e);
        }
    }
}

Unfortunately the OpenReadCompletedEventArgs type doesn’t have a public constructor so I cannot create one myself so I have to use a TestableOpenReadCompletedEventArgs instead. This class looks like this:

public class TestableOpenReadCompletedEventArgs : AsyncCompletedEventArgs
{
    public TestableOpenReadCompletedEventArgs(
        Stream result, Exception error, bool cancelled, object userState)
        : base(error, cancelled, userState)
    {
        Result = result;
    }

    public TestableOpenReadCompletedEventArgs(
        OpenReadCompletedEventArgs args)
        : base(args.Error, args.Cancelled, args.UserState)
    {
        Result = args.Result;
    }

    public Stream Result { get; private set; }
}

So with these new classes I can change the PhotoSearchByUser function to use the new class and it now looks like this:

public void PhotoSearchByUser(string userId, Action<Photo> action)
{
    string url = string.Format(
        @"{0}/?method={1}&api_key={2}&user_id={3}&extras=original_format",
        _flickrUrl, "flickr.photos.search", App.FlickrApiKey, userId);

    TestableWebClient client = new TestableWebClient();
    client.OpenReadCompleted += (sender, e) =>
    {
        if (e.Error == null)
        {
            FlickrResponse response = DeserializeResult(e.Result);
            if (response.Status == "ok")
            {
                foreach (var photo in response.Photos.Photos)
                    action(photo);

                if (response.Photos.Page < response.Photos.PageCount)
                {
                    string nextUrl = string.Format("{0}&page={1}", 
                        url, response.Photos.Page + 1);
                    client.OpenReadAsync(new Uri(nextUrl));
                }
            }
        }
    };

    client.OpenReadAsync(new Uri(url));
}

Not much changes, in fact only a single line changed but we are not quite there yet. We still need a way to get our unit tests to use a different TestableWebClient implementation. Do do so I will pass in the type of TestableWebClient to use with the FlickrRequest constructor. Check the new code:

public class FlickrRequest
{
    private string _flickrUrl = "http://api.flickr.com/services/rest";
    private Type _webClientType = typeof(TestableWebClient);

    public FlickrRequest()
    {
    }

    public FlickrRequest(Type webClientType)
    {
        _webClientType = webClientType;
    }

    public void PhotoSearchByUser(string userId, Action<Photo> action)
    {
        string url = string.Format(
            @"{0}/?method={1}&api_key={2}&user_id={3}&extras=original_format",
            _flickrUrl, "flickr.photos.search", App.FlickrApiKey, userId);

        TestableWebClient client = (TestableWebClient)
            Activator.CreateInstance(_webClientType);
        
        // Rest of the code left out.
    }
}

Now we can start testing this code

I created two unit tests for this code as an example, they look like this:

[TestClass]
public class FlickrDownloadTest : SilverlightTest
{
    [TestMethod]
    [Asynchronous]
    public void Test1()
    {
        FlickrRequest request = new FlickrRequest(typeof(MockTestableWebClient));

        request.PhotoSearchByUser("97044050@N00", (photo) => EnqueueTestComplete());
    }
    
    [TestMethod]
    [Asynchronous]
    public void Test2()
    {
        int pageCount = 0;
        FlickrRequest request = new FlickrRequest(typeof(MockTestableWebClient));

        request.PhotoSearchByUser("97044050@N00", (photo) => pageCount++);
        EnqueueConditional(() =>
            {
                return pageCount == 5;
            });
        EnqueueTestComplete();
    }
}

The fake, or mock, WebClient looks like this:

public class MockTestableWebClient : TestableWebClient
{
    private int _page = 0;

    public override void OpenReadAsync(Uri address)
    {
        _page++;

        FlickrResponse response = new FlickrResponse();
        response.Status = "ok";
        response.Photos = new ResponsePhotoCollection();
        response.Photos.Page = _page;
        response.Photos.PageCount = 5;
        response.Photos.Photos = new Photo[] { new Photo() };
        Stream stream = SerializeResult(response);
        stream.Position = 0;
        TestableOpenReadCompletedEventArgs args = 
            new TestableOpenReadCompletedEventArgs(stream, null, false, null);
        OnOpenReadCompleted(args);
    }


    public static Stream SerializeResult(FlickrResponse response)
    {
        MemoryStream stream = new MemoryStream();
        XmlSerializer ser = new XmlSerializer(typeof(FlickrResponse));
        ser.Serialize(stream, response);

        return stream;
    }
}

Basically I just return a response stating that there are 5 pages and each contains a single blank photo.

Running these tests produces the following output showing both tests passed

Am I happy with the changes I had to make to the Silverlight app to make it unit testable? Well yes and no. I didn’t like having to create a wrapper class for the WebClient and the OpenReadCompletedEventArgs. Bit now that I have done so creating using other test for code using the WebClient is a lot easier. In this case I only added the OpenReadAsync() function but doing the same with the other functions is a breeze. And the end result is I could unit test the code in PhotoSearchByUser() pretty much the way I wrote it without having to change the code a lot just to make it unit testable and that is good! So overall I am reasonably happy with the result

I pretty much skipped all details of the actual unit testing code itself. Now there is some new stuff so in a future blog post I am going to explain what I did in the unit tests themselves.

And thanks to Jeff Wilcox for providing some useful feedback.

Enjoy!

Update: Part 1, Part 2, Part 3.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

PDC session download

Maurice — Sat, 01 Nov 2008 10:17:52 GMT

Want to download and watch all PDC content? Then there are a couple of ways to get at them. The official way if to go through the session agenda at the conference site. See https://sessions.microsoftpdc.com/public/timeline.aspx. You see all sessions but it takes a bit of work. Another nice way is through Channel 9 by using the following feed: http://channel9.msdn.com/posts/pdc2008/RSS/?tag=videos.

But the best as far as I am concerned is using the list compiled by Greg Duncan. Check this list http://coolthingoftheday.blogspot.com/2008/10/pdc2008-quick-video-link-list.html. And it even has the Visual Basic source code used to generate the list

Enjoy the videos!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Using the ReplicatorActivity in Parallel mode

Maurice — Wed, 22 Oct 2008 15:17:11 GMT

I have heard quite a few times that the ReplicatorActivity can only be use in parallel mode with a custom activity. The reason being that you need an extra property to store the current child data.

When the ReplicatorActivity works in sequential mode the following code works just fine:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    int value = (int)replicatorActivity1.CurrentChildData[replicatorActivity1.CurrentIndex];
    Console.WriteLine("Loop value = {0}", value);
}

However when run in parallel the current index always point to the last item so this doesn't work. As an aside I think this is a bug as it results in hard to find errors. IMHO the ReplicatorActivity CurrentIndex should be -1 or some other value that would trigger either an IndexOutOfRangeException or an InvalidOperationException. Unfortunately that is not the case .

Instead when we set the mode to parallel we need to use the ChildInitialized event to save the child data for that loop. So we need a place to store it.

Traditional thinking results in an extra property being added that is being scoped to the loop and an extra property means a custom activity to add it to.

But wait a minute doesn't every workflow foundation activity derive from DependencyObject and isn't that class all about using dependency properties?

Yes it is and that is exactly the reason you don't need a custom activity. In fact you can add as much extra data to any activity as you like!

How to add custom data to the standard activities

The trick is in using a DependencyProperty that is created using the DependencyProperty.RegisterAttached() function. This creates an attached property you can use to store data in activities that have no clue about the data. So the first step is to create a dependency property like this:

public static DependencyProperty LoopValueProperty = 
    DependencyProperty.RegisterAttached("LoopValue", typeof(int), typeof(Workflow1));

Now in the ChildInitialized event we van store the loop value in child activity like this:

private void replicatorActivity1_ChildInitialized(
    object sender, 
    ReplicatorChildEventArgs e)
{
    e.Activity.SetValue(LoopValueProperty, e.InstanceData);
}

Easy right

So if I add a code activity as the child just to print the data all I need is the following code:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    Activity activity = (Activity)sender;
    int value = (int)activity.GetValue(LoopValueProperty);
    Console.WriteLine("The current value = {0}", value); 
}

A slightly larger example showing the parallel behavior

Below is a slightly more complex example showing this. I have added a DelayActivity with a random timeout just to show that the ReplicatorActivity is really running in parallel.

The workflow looks like this:

And when run this produces the following output:

The complete code behind file looks like this:

public sealed partial class Workflow1 : SequentialWorkflowActivity
{
    public Workflow1()
    {
        InitializeComponent();
    }

    public static DependencyProperty LoopValueProperty = 
        DependencyProperty.RegisterAttached("LoopValue", typeof(int), typeof(Workflow1));


    private void replicatorActivity1_Initialized(object sender, EventArgs e)
    {
        ReplicatorActivity replicator = (ReplicatorActivity)sender;
        replicator.InitialChildData = new List<int>(Enumerable.Range(1, 20));
    }

    private void delayActivity1_InitializeTimeoutDuration(object sender, EventArgs e)
    {
        DelayActivity delay = (DelayActivity)sender;
        Random random = new Random();
        delay.TimeoutDuration = TimeSpan.FromSeconds(random.Next(5));
    }

    private void replicatorActivity1_ChildInitialized(
        object sender, 
        ReplicatorChildEventArgs e)
    {
        e.Activity.SetValue(LoopValueProperty, e.InstanceData);
    }

    private void codeActivity1_ExecuteCode(object sender, EventArgs e)
    {
        Activity activity = (Activity)sender;
        int value = (int)activity.Parent.GetValue(LoopValueProperty);
        Console.WriteLine("The current value = {0}", value);
    }
}

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Red Gate to continue development of .NET Reflector

Maurice — Wed, 20 Aug 2008 07:04:54 GMT

.NET Reflector, by Lutz Roeder, must be one of the most useful tools I have when developing .NET code. Usually it is the first thing I install right after Visual Studio not even waiting until I need it because I know I will.

So the big news is that Red Gate, makers of the Ants profiler and lots of other tools, are taking over from Lutz Roeder and will continue developing .NET Reflector. Interesting move and I hope this means a bright future for the .NET Reflector.

Using a TransactionScopeActivity within a ReceiveActivity in a state machine workflow

Maurice — Wed, 13 Aug 2008 10:31:45 GMT

Part 1
part 2
Part 3
Part 4

In two previous blog posts, part one and part two, I covered the fact that the ReceiveActivity and the TransactionScopeActivity don't work together very well. I demonstrated this using a sequential workflow and did show a, clumsy and hacky, workaround to get at least the initial request working. So while the request that starts the sequential workflow could work the same is not true for any subsequent calls.

But what about a state workflow?

State workflow's are very different then sequential workflow's because they are completely event driven. With every state you need to add an EventDrivenActivity and the first child should implement the IEventActivity interface. Well the ReceiveActivity does just that so we can use it to initiate a state machine workflow and triggers its events. However as you might expect a TransactionScopeActivity is not an IEventActivity so it cannot be the first child of the EventDrivenActivity. And that means you cannot wrap the ReceiveActivity inside of an TransactionScopeActivity, something that sort of solved the problem with a sequential workflow. Of course nesting the TransactionScopeActivity inside of the ReceiveActivity won't work either for the reasons described in the first two post. So far so bad

So we need another workaround

Again there is no real good workaround . In fact the only one I can come up with is stop using the TransactionScopeActivity all together. So how to do transactions without using the TransactionScopeActivity?

Well the solution, ahem workaround, is to use the WorkflowEnvironment.WorkBatch object and add all pending work to it. The first parameter is an object of type IPendingWork and this is the one that is actually going to be called to do the work. The second parameter, the workItem, contains the data. Now when a workflow per persistence point is reached the IPendingWork object is called to do its work.

[Serializable()]
class Workflow1PendingWork : IPendingWork
{
    #region IPendingWork Members

    public void Commit(Transaction transaction, ICollection items)
    {
        foreach (var Workflow1PendingWork in items)
        {
            using (TransactionScope tx = new TransactionScope(transaction))
            {
                // Do my own transaction work
                tx.Complete();
            }
        }
    }

    public void Complete(bool succeeded, ICollection items)
    {
    }

    public bool MustCommit(ICollection items)
    {
        /// We want to commit!
        return true;
    }

    #endregion
}

The MustCommit function is called to check if the Commit needs to be called. The Commit itself is called as part of the workflow persistence point. Now you can use something like a CodeActivity and add your workItem to the batch like this:

WorkflowEnvironment.WorkBatch.Add(_pendingWork, myTransactionData);

When do we reach a persistence point?

This leaves us with the question of when these persistence point occur. The best way to think if these is when a workflow reaches a state that is final, no matter what happens. This includes the point where a workflow is done and when it is persisted to the persistence store. Using the SqlWorkflowPersistenceService with the PersistOnIdle option set to true will mean this will happen as soon as the event handler is done executing and the workflow is idle. However sometimes that just isn't good enough and you need to do so sooner. Well the easiest way is to create a custom activity, I call it the PersistStateActivity, and decorate it with the PersistOnClose attribute. No need to add any code, all we are interested in is the attribute.

[PersistOnClose()]
public partial class PersistStateActivity : Activity
{
    public PersistStateActivity()
    {
    }
}

Now drop the activity at any point where you want your transactional data to be committed and the workflow runtime will take care of things for you

Conclusion

Although these workarounds are possible they are all but intuitive and it took quite a bit of digging around and brainstorming with some people to get this to work. So be very careful when using the TransactionScopeActivity, or any form of transactions for that matter, and the WCF ReceiveActivity!

Enjoy!

Visual Studio 2008 Service Pack 1 available

Maurice — Mon, 11 Aug 2008 15:33:33 GMT

It is available from the subscriptions download at http://msdn.microsoft.com/en-us/subscriptions/default.aspx

Get it while it is hot

Enjoy!