Arrange Act Assert » Silverlight

How to use DesignData to populate controls with design time data in Silverlight and WPF

Jag Reehal — Fri, 06 Aug 2010 00:00:52 +0000

In this post I’ll be showing how you can use DesignData to populate controls when you’re designing Silverlight or WPF applications in Expression Blend or Visual Studio.

The image below shows a user control in Expression Blend which allows users take part in a poll to find out what their favorite colors of the rainbow are.

As you can see it’s difficult if not impossible to imagine what we are actually designing here.

The user control doesn’t look any better in Visual Studio 2010.

Creating the ViewModel for the Object Data Source

The code for the ViewModel we want to create sample data for is shown below.

public class ViewModel : INotifyPropertyChanged
{
    private string _name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get { return _name; }
        set
        {
            _name = value;
            OnPropertyChanged("Name");
        }
    }

    public ObservableCollection RainbowColors { get; set; }

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

public class RainbowColor
{
    public string Description { get; set; }
    public string Color { get; set; }
}

The bit where Expression Blend flexes it muscles

If you’re using Expression Blend the good news is that creating sample data can be done in a couple of clicks.

In the Data tab click on the ‘Create data source’ button to see the following window

Next select ViewModel as the object to create the data source for

This will create a XAML file populated with sample data, which has been modified to be the colors of the rainbow.

Creating DesignData in Visual Studio

In Visual Studio you have to create the XAML file manually and change the build action for it to DesignData as shown below.

My recommendation is to store the XAML files containing sample data in a SampleData sub folder (which Expression Blend does by default).

Setting the DataContext to use DesignData in XAML

In order to bind the sample data to the user control during design time we need to add a few more lines in the opening tag.

The lines that use DesignData to bind data in the designer are highlighted in the XAML for the user control below.

Pay attention to the line

mc:Ignorable="d"

If you don’t add this you will see the following error when you try to compile the solution

XAML Namespace http://schemas.microsoft.com/expression/blend/2008 is not resolved.

If you’re using Expression Blend the designer will now look like this

or like this if you’re using Visual Studio 2010

Does it matter if I’m using MVVM or not?

No. Even though I’m using a ViewModel in this example, all that matters is that you can bind your sample data to the data context of the control.

How design time data will save you time designing Silverlight and WPF applications

Jag Reehal — Fri, 06 Aug 2010 00:00:26 +0000

When it comes to designing applications it’s definitely a lot easier when you can visualize what you’re creating without actually running the solution.

So why should it be any different for Silverlight and WPF?

If you just want to know how you can populate controls during design time the links below show three (of the many) ways you can populate your pages, windows, user controls, grids etc with sample data in Expression Blend or Visual Studio.

How to use a designinstance to populate controls with design time data in Silverlight and WPF

How to use DesignData to populate controls with design time data in Silverlight and WPF

How to use the DesignerProperties.IsInDesignTool property to populate controls with design time data in Silverlight

How to use the DesignerProperties.GetIsInDesignMode method to populate controls with design time data in WPF

Why populating controls with design time data in Silverlight and WPF will improve your productivity

Let’s image for a moment we were given the task of designing a Silverlight application to find out what colors of the rainbow are the most popular.

The SketchFlow prototype below shows what we are aiming for.

Well this is easy enough isn’t it? The XAML below should do the job.

Spot any problems, issues or flaws yet?

If we run this application this is what is shown to the user.

As you can see there is a problem with the ListBoxItem not stretching to the width of the grid.

If you had used deign time data this is what you would have seen in Expression Blend.

Still not convinced design time data will help you?

Well in that case have fun implementing a fix, running the application, implementing another fix, running the application again until you’ve resolved the issue or ran out of time.

Jag Reehal’s Final Thought on ‘How design time data will save you time designing Silverlight and WPF applications’

Designing is so much easier when you’re able to see controls populated with sample data because you will be able to find and resolve design issues and problems quicker using design time data.

How to use the DesignerProperties.IsInDesignTool property to populate controls with design time data in Silverlight using Expression Blend

Jag Reehal — Fri, 06 Aug 2010 00:00:19 +0000

In this post I’ll be showing how you can use the DesignerProperties.IsInDesignTool property to populate controls when you’re designing Silverlight applications in Expression Blend.

This solution does not work in Visual Studio 2010. To find out about what options do work in Visual Studio check out the following posts:

If you’re looking for a WPF solution using DesignerProperties check out the post ‘How to use the DesignerProperties.GetIsInDesignMode method to populate controls with design time data in WPF‘

The image below shows a user control in Expression Blend which allows users take part in a poll to find out what their favorite colors of the rainbow are.

As you can see it’s difficult if not impossible to imagine what we are actually designing here.

Creating a ViewModelProvider a.k.a ViewModel ServiceLocator

Essentially what we want is to use a ViewModel populated with sample data during design time and the actual ViewModel when the application is running.

To do this we can use the ViewModel and DesignTimeViewModel classes shown below.

public class ViewModel : INotifyPropertyChanged
{
    private string _name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get { return _name; }
        set
        {
            _name = value;
            OnPropertyChanged("Name");
        }
    }

    public ObservableCollection RainbowColors { get; set; }

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

public class DesignTimeViewModel : ViewModel
{
    public DesignTimeViewModel()
    {
        Name = "Roy G Biv";
        RainbowColors = new ObservableCollection()
                        {
                            new RainbowColor() {Description = "Red", Color =  "#FFFF0000"},
                            new RainbowColor() {Description = "Orange", Color =  "#FFFFA500"},
                            new RainbowColor() {Description = "Yellow", Color =  "#FFFFFF00"},
                            new RainbowColor() {Description = "Green", Color =  "#FF008000"},
                            new RainbowColor() {Description = "Blue", Color =  "#FF0000FF"},
                            new RainbowColor() {Description = "Indigo", Color =  "#FF4B0082"},
                            new RainbowColor() {Description = "Violet", Color =  "#FFEE82EE"}
                        };
    }
}

public class RainbowColor
{
    public string Description { get; set; }
    public string Color { get; set; }
}

A provider/service locater class allows Expression Blend to determine which ViewModel to use.

public class ViewModelProvider
{
    public ViewModel ViewModel
    {
        get
        {
            if (DesignerProperties.IsInDesignTool)
            {
                return new DesignTimeViewModel();
            }
            return new ViewModel();
        }
    }
}

Setting the DataContext to use the ViewModelProvider in XAML

In order to bind the sample data to the user control during design time we need to add a line in the opening tag, create a resource and set the data context to use the ViewModel returned by the provider/service locator.

The lines to do this are highlighted in the XAML for the user control below.

The Expression Blend designer will now look like this

Does it matter if I’m using MVVM or not?

No. Even though I’m using a ViewModel in this example, all that matters is that you can bind your sample data to the data context of the control.

How to use a DesignInstance to populate controls with design time data in Silverlight and WPF

Jag Reehal — Fri, 06 Aug 2010 00:00:17 +0000

In this post I’ll be showing how you can use a DesignInstance to populate controls when you’re designing Silverlight or WPF applications in Expression Blend or Visual Studio.

The image below shows a user control in Expression Blend which allows users take part in a poll to find out what their favorite colors of the rainbow are.

As you can see it’s difficult if not impossible to imagine what we are actually designing here.

The user control doesn’t look any better in Visual Studio 2010.

Creating the ViewModel to bind the data context using DesignInstance

The code below shows the DesignTimeViewModel class to be used as the data context during design time. It inherits from the ViewModel class which will be used when the application is actually running.

public class DesignTimeViewModel : ViewModel
{
    public DesignTimeViewModel()
    {
        Name = "Roy G Biv";
        RainbowColors = new ObservableCollection()
                            {
                                new RainbowColor() {Description = "Red", Color =  "#FFFF0000"},
                                new RainbowColor() {Description = "Orange", Color =  "#FFFFA500"},
                                new RainbowColor() {Description = "Yellow", Color =  "#FFFFFF00"},
                                new RainbowColor() {Description = "Green", Color =  "#FF008000"},
                                new RainbowColor() {Description = "Blue", Color =  "#FF0000FF"},
                                new RainbowColor() {Description = "Indigo", Color =  "#FF4B0082"},
                                new RainbowColor() {Description = "Violet", Color =  "#FFEE82EE"}
                            };
    }
}

public class ViewModel : INotifyPropertyChanged
{
    private string _name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get { return _name; }
        set
        {
            _name = value;
            OnPropertyChanged("Name");
        }
    }

    public ObservableCollection RainbowColors { get; set; }

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

public class RainbowColor
{
    public string Description { get; set; }
    public string Color { get; set; }
}

Setting the DataContext to use DesignInstance in XAML

In order to bind the DesignTimeViewModel to the user control during design time we need to add a few more lines in the opening tag.

The lines that use a DesignInstance to bind data in the designer are highlighted in the XAML for the user control below.

Pay attention to the line

mc:Ignorable="d"

If you don’t add this you will see the following error when you try to compile the solution

XAML Namespace http://schemas.microsoft.com/expression/blend/2008 is not resolved.

If you’re using Expression Blend the designer will now look like this

or like this if you’re using Visual Studio 2010

Does it matter if I’m using MVVM or not?

No. Even though I’m using a ViewModel in this example, all that matters is that you can bind your sample data to the data context of the control.

Using INotifyDataErrorInfo for validation in MVVM with Silverlight

Jag Reehal — Thu, 15 Jul 2010 23:13:15 +0000

In this post we will be looking at how validation can be done by implementing the INotifyDataErrorInfo interface for a calculator we have been building as part of the Silverlight refactoring series.

Like the IDataErrorInfo interface, the INotifyDataErrorInfo interface gives you the ability to do validation without throwing exceptions.

The full solution for this post can be downloaded here.

Note to WPF developers – INotifyDataErrorInfo isn’t available in WPF (yet)

But you can vote for INotifyDataErrorInfo to be in a future release of WPF.

Pre INotifyDataErrorInfo

As you can see in the code below we are throwing exceptions in the setters for the two values we want to add together.

public string  FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("FirstValue");
    }
}
public string  SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        try
        {
            int.Parse(_secondValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("SecondValue");
    }
}

Implementing the INotifyDataErrorInfo interface

As we only want the calculate button to be enabled when the user has entered valid numbers to add together, we need to keep track of any validation errors.

Similar to how we have done in other posts, we will use a class for storing validation errors instead of making it the responsibility of the ViewModel.

And that class is the EntityBase class, which I borrowed from Mike Taulty. Cheers Mike!

The code below shows how the EntityBase class implements the ErrorsChanged event, GetErrors method and the HasErrors property defined in the INotifyDataErrorInfo interface.

public class EntityBase : INotifyDataErrorInfo
{
    public event EventHandler ErrorsChanged;
    readonly Dictionary> _currentErrors;

    public EntityBase()
    {
        _currentErrors = new Dictionary>();
    }

    public IEnumerable GetErrors(string propertyName)
    {
        if (string.IsNullOrEmpty(propertyName))
        {
            return (_currentErrors.Values);
        }

        MakeOrCreatePropertyErrorList(propertyName);
        return _currentErrors[propertyName];
    }

    public bool HasErrors
    {
        get
        {
            return (_currentErrors.Where(c => c.Value.Count > 0).Count() > 0);
        }
    }

    void FireErrorsChanged(string property)
    {
        if (ErrorsChanged != null)
        {
            ErrorsChanged(this, new DataErrorsChangedEventArgs(property));
        }
    }
    public void ClearErrorFromProperty(string property)
    {
        MakeOrCreatePropertyErrorList(property);
        _currentErrors[property].Clear();
        FireErrorsChanged(property);
    }
    public void AddErrorForProperty(string property, string error)
    {
        MakeOrCreatePropertyErrorList(property);
        _currentErrors[property].Add(error);
        FireErrorsChanged(property);
    }

    void MakeOrCreatePropertyErrorList(string propertyName)
    {
        if (!_currentErrors.ContainsKey(propertyName))
        {
            _currentErrors[propertyName] = new List();
        }
    }
}

The EnitityBase class can be unit tested like this

[TestFixture]
public class When_using_the_EntityBase
{
    private EntityBase _entityBase;

    [SetUp]
    public void SetUp()
    {
        _entityBase = new EntityBase();
    }

    [Test]
    public void HasErrors_should_return_true_when_errors_exist()
    {
        // Arrange
        _entityBase.AddErrorForProperty("X", "X");

        // Act
        var result = _entityBase.HasErrors;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void HasErrors_should_return_true_when_no_errors_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _entityBase.HasErrors;

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void Should_be_able_to_clear_error_from_property()
    {
        // Arrange
        _entityBase.AddErrorForProperty("X", "X");

        // Act
        _entityBase.ClearErrorFromProperty("X");
        var result = _entityBase.GetErrors("X") as List; 

        // Assert
        result.Count().ShouldEqual(0);

    }

    [Test]
    public void Should_be_able_to_get_error_for_property()
    {
        // Arrange
        const string errorMessage = "ErrorMessage";
        _entityBase.AddErrorForProperty("X", "ErrorMessage");

        // Act
        var result =  _entityBase.GetErrors("X") as List;

        // Assert
        result[0].ShouldEqual(errorMessage);

    }
}

How the ViewModel validates user input

We need to validate the users input each time the value of a property changes.

If you have been following the series you’ll know the benefits of injecting/importing a class responsible for validation, the CalculatorValidator, into the ViewModel and to validate the users input.

In the code for the CalculatorValidator class, the Validate method could have returned a collection of error messages, but to keep this example simple we’ll just return the first validation error we encounter.

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ICalculatorValidator
{
    [ImportMany]
    public IEnumerable CalculatorValidationRules { get; set; }

    public ValidationResult Validate(string value)
    {
        List validationResults = new List();
        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                return new ValidationResult()
                            {
                                IsValid = false,
                                ErrorMessage = calculatorValidationRule.ErrorMessage

                            };
            }
        }
        return new ValidationResult() { IsValid = true };
    }
}

public class ValidationResult
{
    public bool IsValid { get; set; }
    public string ErrorMessage { get; set; }
}

If you’re new to the series the validation rules for calculator are being imported by MEF. Read how and why we are doing this in the ‘Applying the Open Closed Principle in Silverlight and WPF using MEF‘ post.

Using the INotifyDataErrorInfo interface in the ViewModel

In the code for the ViewModel shown below take note of how:

the ViewModel inherits from the EntityBase class
the CheckIfNumberIsValid method is called whenever a property value changes
the INotifyDataErrorInfo HasErrors property is used to determine if the button should be enabled in the CalculatorViewModel_ErrorsChanged handler for the ErrorsChanged event. This is one of the advantages INotifyDataErrorInfo has over IDataErrorInfo.

[Export]
public class CalculatorViewModel : EntityBase, INotifyPropertyChanged
{
    private string _firstValue;
    private string _secondValue;
    private string _result;       

    private readonly ICalculator _calculator;
    private readonly RelayCommand _calculateCommand;

    public event PropertyChangedEventHandler PropertyChanged;
    public ObservableCollection FirstValueErrors { get; set; }
    private readonly ICalculatorValidator _calculatorValidator;

    [ImportingConstructor]
    public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
    {
        _calculator = calculator;
        _calculatorValidator = calculatorValidator;
        _calculateCommand = new RelayCommand(Calculate) { IsEnabled = true };
        ErrorsChanged += new EventHandler(CalculatorViewModel_ErrorsChanged);

        _firstValue = "0";
        _secondValue = "0";
    }

    void CalculatorViewModel_ErrorsChanged(object sender, DataErrorsChangedEventArgs e)
    {
        _calculateCommand.IsEnabled = HasErrors == false;
    }

    public void Calculate()
    {
        Result = _calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
    }

    public string FirstValue
    {
        get { return _firstValue; }
        set
        {
            _firstValue = value;
            CheckIfNumberIsValid("FirstValue", value);
        }
    }

    public string SecondValue
    {
        get { return _secondValue; }
        set
        {
            _secondValue = value;
            CheckIfNumberIsValid("SecondValue", value);
        }
    }

    public void CheckIfNumberIsValid(string propertyName, string value)
    {
        ClearErrorFromProperty(propertyName);

        var validationResult = _calculatorValidator.Validate(value);
        if (validationResult.IsValid  == false)
        {
            AddErrorForProperty(propertyName, validationResult.ErrorMessage);
        }
        OnPropertyChanged(propertyName);
    }

    public string Result
    {
        get { return _result; }
        private set
        {
            _result = value;
            OnPropertyChanged("Result");
        }
    }

    public RelayCommand CalculateCommand
    {
        get { return _calculateCommand; }
    }

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

XAML changes for INotifyDataErrorInfo

The final change required to implement INotifyDataErrorInfo interface is to change the text box bindings and set ValidatesOnNotifyDataErrors=True

So what have we achieved?

In this post we have refactored the code to use the INotifyDataErrorInfo interface and are no longer throwing exceptions to do validation.

As well as allowing you return multiple validation errors for a property, the INotifyDataErrorInfo interface can be used for asynchronous data validation as demonstrated by Jesse Liberty in this video.

Using IDataErrorInfo for validation in MVVM with Silverlight and WPF

Jag Reehal — Tue, 06 Jul 2010 23:01:57 +0000

In this post we will be looking at how validation can be done by implementing the IDataErrorInfo interface for a calculator we have been building as part of the Silverlight refactoring series.

The IDataErrorInfo interface gives you the ability to do validation without throwing exceptions.

The full solution for this post can be downloaded here.

Pre IDataErrorInfo

As you can see in the code below we are throwing exceptions in the setters for the two values we want to add together.

public string  FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("FirstValue");
    }
}
public string  SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        try
        {
            int.Parse(_secondValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("SecondValue");
    }
}

Implementing the IDataErrorInfo interface

The IDataErrorInfo interface consists of two properties.

string this[string columnName] {get;}
string Error {get;}

For the Error property we can just return null because we don’t want to return a single error message for the entire object.

public string Error
{
    get { return null; }
}

For the property which returns an error for a text box we could do the validation like this

public string this[string columnName]
{
    get
    {
        string error = null;
        switch (columnName)
        {
            case "FirstValue":
                try
                {
                    int.Parse(_firstValue);
                }
                catch (Exception)
                {
                    error = "That is not a number";
                }
                break;
            case "SecondValue":
                try
                {
                    int.Parse(_firstValue);
                }
                catch (Exception)
                {
                    error = "That is not a number";
                }
                break;
        }
        return error;
    }
}

But as we saw in a previous post about using ValidatesOnExceptions to do validation it’s much easier to write unit tests when there are separation of concerns and the ViewModel is not responsible for validation.

So this means we need to create a class for storing the validation error for each textbox

public class ValidationBase
{
    public readonly Dictionary Errors;

    public ValidationBase()
    {
        Errors = new Dictionary();
    }

    public void AddError(string propertyName, string message)
    {
        if (!Errors.ContainsKey(propertyName))
        {
            Errors[propertyName] = message;
        }
    }

    public void RemoveErrors(string propertyName)
    {
        Errors.Remove(propertyName);
    }

    public string GetErrorMessageForProperty(string propertyName)
    {
        string message;
        Errors.TryGetValue(propertyName, out message);
        return message;
    }

    public bool HasErrors()
    {
        return Errors.Count != 0;
    }
}

which is inherited by a CalculatorValidator class that returns a boolean value if the property value is not valid

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ValidationBase, ICalculatorValidator
{
    [ImportMany]
    public IEnumerable CalculatorValidationRules { get; set; }

    public bool IsPropertyValid(string propertyName, string value)
    {
        RemoveErrors(propertyName);
        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                AddError(propertyName, calculatorValidationRule.ErrorMessage);
                return false;
            }
        }
        return true;
    }
}

Now we can inject/import the CalculatorValidator into the ViewModel and use it to validate the users input.

As we only want the user to be able to click the calculate button when the form is valid we call we the CheckIfCalculteButtonShouldBeEnabled method when a text box value has changed.

[Export]
public class CalculatorViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    private string _firstValue;
    private string _secondValue;
    private string _result;

    private readonly ICalculator _calculator;
    private readonly RelayCommand _calculateCommand;

    public event PropertyChangedEventHandler PropertyChanged;
    private readonly ICalculatorValidator _calculatorValidator;

    [ImportingConstructor]
    public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
    {
        _calculator = calculator;
        _calculatorValidator = calculatorValidator;
        _calculateCommand = new RelayCommand(Calculate) { IsEnabled = true };

        _firstValue = "0";
        _secondValue = "0";
    }
    public void Calculate()
    {
        Result = _calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
    }

    public string FirstValue
    {
        get { return _firstValue; }
        set
        {
            _firstValue = value;
            OnPropertyChanged("FirstValue");
        }
    }

    public string SecondValue
    {
        get { return _secondValue; }
        set
        {
            _secondValue = value;
            OnPropertyChanged("SecondValue");
        }
    }

    public void CheckIfCalculteButtonShouldBeEnabled()
    {
        _calculateCommand.IsEnabled = _calculatorValidator.HasErrors() == false;
    }

    public string Result
    {
        get { return _result; }
        private set
        {
            _result = value;
            OnPropertyChanged("Result");
        }
    }

    public RelayCommand CalculateCommand
    {
        get { return _calculateCommand; }
    }

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

    public string this[string columnName]
    {
        get
        {
            string error = null;
            switch (columnName)
            {
                case "FirstValue":
                    error = ValidateNumber("FirstValue", _firstValue);
                    break;
                case "SecondValue":
                    error = ValidateNumber("SecondValue", _secondValue);
                    break;
            }

            CheckIfCalculteButtonShouldBeEnabled();
            return error;
        }
    }

    public string ValidateNumber(string propertyName, string value)
    {
        if (!_calculatorValidator.IsPropertyValid(propertyName, value))
        {
            return _calculatorValidator.GetErrorMessageForProperty(propertyName);
        }
        return null;
    }

    public string Error
    {
        get { return null; }
    }
}

The code below shows how we can unit test the ViewModel which implements the IDataErrorInfo interface.

[TestFixture]
public class When_using_the_CalculatorViewModel
{
    private Mock _calculator;
    private Mock _calculatorValidator;
    private CalculatorViewModel _calculatorViewModel;

    [SetUp]
    public void SetUp()
    {
        _calculator = new Mock();
        _calculatorValidator = new Mock();
        _calculatorViewModel = new CalculatorViewModel(_calculator.Object, _calculatorValidator.Object);
    }

    [Test]
    public void Initial_value_of_first_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.FirstValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_second_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.SecondValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_calculate_button_is_enabled()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.CalculateCommand.IsEnabled;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void ValidateNumber_returns_null_if_value_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsPropertyValid("X","X")).Returns(true);

        // Act
        var result = _calculatorViewModel.ValidateNumber("X","X");

        // Assert
        result.ShouldBeNull();
    }

    [Test]
    public void ValidateNumber_returns_error_message_if_value_is_not_valid()
    {
        // Arrange
        const string errorMessage = "ErrorMessageText";
        _calculatorValidator.Setup(c => c.IsPropertyValid("X", "X")).Returns(false);
        _calculatorValidator.Setup(c => c.GetErrorMessageForProperty("X")).Returns(errorMessage);

        // Act
        var result = _calculatorViewModel.ValidateNumber("X", "X");

        // Assert
        result.ShouldEqual(errorMessage);
    }

    [Test]
    public void Calculate_command_should_not_be_enabled_if_ViewModel_is_not_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.HasErrors()).Returns(true);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeFalse();
    }

    [Test]
    public void Calculate_command_should_be_enabled_if_ViewModel_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.HasErrors()).Returns(false);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeTrue();
    }
}

The final change we need to make is to change the text box binding to ValidatesOnDataErrors=True in the XAML file.

So what have we achieved?

In this post we have refactored the code to use the IDataErrorInfo interface and are no longer throwing exceptions to do validation.

Whether you choose to use it or not depends if you want multiple errors for a single property to be combined into a single error message.

Enabling buttons in Silverlight and WPF using MVVM and ValidatesOnExceptions

Jag Reehal — Mon, 05 Jul 2010 23:10:40 +0000

In a previous post we saw how exceptions could be used for Silverlight validation.

While could validate the users input using exceptions, it wasn’t possible to disable the calculate button if the input values were invalid (because they were either blank or non-numeric).

The code used in this post can be downloaded here.

So how are we going to solve the problem?

Throughout the Silverlight refactoring series I’ve tried to illustrate how important SOLID design principles are for having testable applications.

So if we think about the ViewModel, we need to ask ourselves if it’s the right place or should be responsible for validation?

In this case I would say no.

When should the button be enabled?

For a calculate button to be enabled, both text boxes must contain numeric values

This means we have to know if both text boxes are valid at the same time. Taking a step back here, let’s think about the bigger picture.

What if there are three or four text boxes?

What we really after is a class that will be responsible for knowing if any text boxes are invalid.

This can be done by using a validation base class.

In the code below notice how the ValidationBase class doesn’t know anything about enabling or disabling the calculate button.

public class ValidationBase
{
    public readonly Dictionary Errors;

    public ValidationBase()
    {
        Errors = new Dictionary();
    }

    public void AddError(string propertyName, string message)
    {
        if (!Errors.ContainsKey(propertyName))
        {
            Errors[propertyName] = message;
        }
    }

    public void RemoveErrors(string propertyName)
    {
        Errors.Remove(propertyName);
    }

    public bool IsPropertyValid(string propertyName)
    {
        return !Errors.ContainsKey(propertyName);
    }

    public string GetErrorMessageForProperty(string propertyName)
    {
        string message;
        Errors.TryGetValue(propertyName, out message);
        return message;
    }

    public bool IsValid()
    {
        return Errors.Count == 0;
    }
}

The code below shows the unit tests for the ValidationBase class.

[TestFixture]
public class When_using_the_ValidatiorBase
{
    private ValidationBase _validationBase;

    [SetUp]
    public void SetUp()
    {
        _validationBase = new ValidationBase();
    }

    [Test]
    public void IsValid_should_return_false_when_errors_exist()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.IsValid();

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void IsValid_should_return_true_when_no_errors_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.IsValid();

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void IsPropertyValid_should_return_false_if_error_exists()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.IsPropertyValid("propertyName");

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void IsPropertyValid_should_return_true_if_error_does_not_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.IsPropertyValid("X");

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void Should_be_able_to_return_message_for_error()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.GetErrorMessageForProperty("propertyName");

        // Assert
        result.ShouldEqual("message");
    }

    [Test]
    public void Should_return_null_if_message_does_not_exist_for_error()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.GetErrorMessageForProperty("propertyName");

        // Assert
        result.ShouldBeNull();
    }
}

Validating the users input

There are three outcomes when validating what the user has entered:

The value is blank
The value is not a number
The value is a number

All the ViewModel wants to know is if the users input is valid, choosing the appropriate error message isn’t its concern. This means we need a class that will be responsible for validation and returning the relevant message.

For this we will use the CalculatorValidator class we created in the ‘Applying the Open Closed Principle in Silverlight and WPF using MEF‘ post.

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ValidationBase, ICalculatorValidator
{
    [ImportMany]
    public IEnumerable CalculatorValidationRules { get; set; }

    public void ValidateNumber(string propertyName, string value)
    {
        RemoveErrors(propertyName);

        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                AddError(propertyName, calculatorValidationRule.ErrorMessage);
                return;
            }
        }
    }
}

This is useful because if we decide to change how to validate the user’s input neither the CalculatorValidator or the ViewModel classes need to be modified.

Hooking it all up

To use the CalculatorValidator in the ViewModel it has to be injected/imported.

[ImportingConstructor]
public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
{
    _calculator = calculator;
    _calculatorValidator = calculatorValidator;
    ...
}

Each time a user enters a value in the text boxes the CheckIfNumberIsValid method checks if the calculate button should be enabled and throws an exception if the users value is not valid.

public string FirstValue
{
    get { return _firstValue; }
    set
    {
        CheckIfNumberIsValid("FirstValue", out _firstValue, value);
    }
}

public string SecondValue
{
    get { return _secondValue; }
    set
    {
        CheckIfNumberIsValid("SecondValue", out _secondValue, value);
    }
}

public void CheckIfNumberIsValid(string propertyName, out string propertyValue, string value)
{
    _calculatorValidator.ValidateNumber(propertyName, value);

    CheckIfCalculteButtonShouldBeEnabled();

    if (_calculatorValidator.IsPropertyValid(propertyName))
    {
        propertyValue = value;
        OnPropertyChanged(propertyName);
    }
    else
    {
        throw new Exception(_calculatorValidator.GetErrorMessageForProperty(propertyName));
    }
}

public void CheckIfCalculteButtonShouldBeEnabled()
{
    _calculateCommand.IsEnabled = _calculatorValidator.IsValid();
}

Unit testing the ViewModel in MVVM

By using Moq we can unit test the ViewModel to ensure the button is enabled when there are no validation errors and not enabled when there are validation errors.

[TestFixture]
public class When_using_the_CalculatorViewModel
{
    private Mock _calculator;
    private Mock _calculatorValidator;
    private CalculatorViewModel _calculatorViewModel;

    [SetUp]
    public void SetUp()
    {
        _calculator = new Mock();
        _calculatorValidator = new Mock();
        _calculatorViewModel = new CalculatorViewModel(_calculator.Object, _calculatorValidator.Object);
    }

    [Test]
    public void Initial_value_of_first_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.FirstValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_second_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.SecondValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_calculate_button_is_enabled()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.CalculateCommand.IsEnabled;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    [ExpectedException(typeof(Exception))]
    public void Will_throw_exception_if_input_is_invalid()
    {
        // Arrange
        string propertyValue;
        _calculatorValidator.Setup(c => c.IsPropertyValid("X")).Throws(new Exception());

        // Act
        _calculatorViewModel.CheckIfNumberIsValid("X", out propertyValue, "X");

        // Assert
        // should throw exception
    }

    [Test]
    public void Will_set_property_value_if_input_is_valid()
    {
        // Arrange
        string propertyValue;
        _calculatorValidator.Setup(c => c.IsPropertyValid("X")).Returns(true);

        // Act
        _calculatorViewModel.CheckIfNumberIsValid("X", out propertyValue, "11");

        // Assert
        propertyValue.ShouldEqual("11");

    }

    [Test]
    public void Calculate_command_should_not_be_enabled_if_ViewModel_is_not_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsValid()).Returns(false);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeFalse();
    }

    [Test]
    public void Calculate_command_should_be_enabled_if_ViewModel_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsValid()).Returns(true);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeTrue();
    }
}

So what have we achieved?

By using a validation base class we are able to store validation errors and can determine if the controls on the page are all valid.

The ViewModel can take advantage of this functionality and use it to enable and disable the calculate button.

Using exceptions for validation isn’t every developers cup of tea, so be sure to keep an eye on the Silverlight refactoring series to see other approaches we can take to do validation in Silverlight 4.

Validation in Silverlight and WPF using ValidatesOnExceptions

Jag Reehal — Wed, 30 Jun 2010 23:43:06 +0000

With the application as it is the user is able to enter non-numeric values and add them together.

Clicking the calculate button to add two non-numeric values together will cause the application to do nothing and the user will have no idea why.

Try it for yourself here.

It would be common sense to validate what the user has entered and let them know if and what the problem is.

What I’ve seen most beginners do for validation in Silverlight and WPF

One of easiest way (in terms of the amount of code you have to write) to do validation in Silverlight and WPF is to use exceptions.

To do this we need to make changes in the ViewModel and the Calculator XAML file.

In the ViewModel an exception needs to be thrown when the input value cannot be converted to a number.

public string FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw;
        }
        OnPropertyChanged("FirstValue");
    }
}

In the XAML file we set ValidatesOnExceptions equal to true for the text box binding.

The screenshot below shows what happens if the user does not enter a number into the text box.

As you can see error message isn’t very user friendly.

To resolve this issue we could set the message of the exception thrown when parsing a number but we would be repeating/duplicating code when validating the SecondValue.

public string FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("FirstValue");
    }
}

public string SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("SecondValue");
    }
}

Silverlight validations the Don’t Repeat Yourself Way

A better way would to do this is by creating a reusable method for validating the users input.

void ValidateNumber(string value)
{
    try
    {
        int.Parse(value);
    }
    catch (Exception)
    {
        throw new Exception("That's not a number");
    }
}

which could be used like this

public string FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        ValidateNumber(value);
        OnPropertyChanged("FirstValue");
    }
}

public string SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        ValidateNumber(value);
        OnPropertyChanged("SecondValue");
    }
}

Now when a user enters an invalid number the they would see an error that looks like this

So what have we achieved?

With a few lines of code we are able to validate the users input and let them know what the problem is if it’s not valid.

If you have arrived here from a search engine, this post is part of series about refactoring Silverlight applications.

So if you’re thinking, this is all very well but the user is still able to click the calculate button even if they have entered invalid values to add together, see how this can prevented in the next part of the series.

Applying the Open Closed Principle in Silverlight and WPF using MEF

Jag Reehal — Mon, 28 Jun 2010 23:27:39 +0000

In this post I want to show how MEF can be used to apply the Open Closed Principle where a class is open for extension but closed for modification.

In the Calculator application we have been building as part of the Silverlight refactoring series we could have used the code below to validate a users input.

By the way we are throwing exceptions because the application is using ValidatesOnExceptions.

public class CalculatorValidator
{
    public void ValidateNumber(string value)
    {
        if (String.IsNullOrEmpty(value))
        {
            throw new Exception("Please enter a number");
        }

        int number;
        if (!int.TryParse(value, out number))
        {
            throw new Exception("That's not a number");
        }
    }
}

If we wanted to add more validation rules to check the value cannot be negative or greater than a hundred we have to modify the CalculatorValidator class with two additional if statements.

public class CalculatorValidator
{
    public void ValidateNumber(string value)
    {
        if (String.IsNullOrEmpty(value))
        {
            throw new Exception("Please enter a number");
        }

        int number;
        if (!int.TryParse(value, out number))
        {
            throw new Exception("That's not a number");
        }

        if (number < 0)
        {
            throw new Exception("Number cannot be negative");
        }

        if (number > 100)
        {
            throw new Exception("That number is too big!");
        }
    }
}

and this pattern would continue every time you added a new rule, leaving the code as maintainable and stable as a wobbly tower!

Implementing the Open Closed Principle

Lets start by creating an interface for a validation rule

public interface ICalculatorValidationRule
{
    bool IsValid(string number);
    string ErrorMessage { get; }
}

Next we create a class for each validation rule by implementing the ICalculatorValidationRule interface

[Export(typeof(ICalculatorValidationRule))]
public class ValidateValueIsNotNullOrEmpty : ICalculatorValidationRule
{
    public bool IsValid(string value)
    {
        return !String.IsNullOrEmpty(value);
    }

    public string ErrorMessage
    {
        get
        {
            return "Please enter a number";
        }
    }
}

[Export(typeof(ICalculatorValidationRule))]
public class ValidateValueIsANumber : ICalculatorValidationRule
{
    public bool IsValid(string value)
    {
        if (!String.IsNullOrEmpty(value))
        {
            int number;
            return int.TryParse(value, out number);
        }
        return true;
    }

    public string ErrorMessage
    {
        get { return "That's not a number"; }
    }
}

[Export(typeof(ICalculatorValidationRule))]
public class ValidateValueIsNotNegative : ICalculatorValidationRule
{
    public bool IsValid(string value)
    {
        int number;
        if (int.TryParse(value, out number) && number  < 0)
        {
            return false;
        }
        return true;
    }

    public string ErrorMessage
    {
        get { return "Number cannot be negative"; }
    }
}

[Export(typeof(ICalculatorValidationRule))]
public class ValidateValueIsLessThanHundred : ICalculatorValidationRule
{
    public bool IsValid(string value)
    {
        int number;
        if (int.TryParse(value, out number) && number > 100)
        {
            return false;
        }
        return true;
    }

    public string ErrorMessage
    {
        get { return "That number is too big!"; }
    }
}

An alternative to parsing the value to an integer in the validation rules to check the range would be to order how MEF composes the validation rules and ensure rule to validate the value is an integer is done earlier.

More information about this can be found in answer to this question on Stack Overflow – How does MEF determine the order of its imports?

ImportMany example in MEF

By using the ImportMany attribute on a collection in MEF we can iterate over all of the parts which export the ICalculatorValidatorInterface and check the value passes the validation rule by calling the IsValid method.

If the value is not valid a exception is thrown with the relevant error message.

The code below shows how the CalculatorValidator class would look

public class CalculatorValidator
{
    [ImportMany]
    public IEnumerable CalculatorValidationRules { get; set; }

    public void ValidateNumber(string value)
    {
        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                throw new Exception(calculatorValidationRule.ErrorMessage);

            }
        }
    }
}

Couldn’t have done it without the extensibility of MEF

If we wanted to add a new validation rule, all we have to do is create another class which implements the ICalculatorValidationRule interface, add an export attribute and MEF will do the rest.

The CalculatorValidator class is now open to extension but closed for modification

SOLID design principles using MEF in Silverlight and WPF

Jag Reehal — Thu, 17 Jun 2010 21:14:01 +0000

In this part of the Silverlight refactoring series we will be looking at two ways the Managed Extensibility Framework (MEF) can help you refactor Silverlight or WPF applications to follow SOLID design principles.

The code used in this post can be downloaded here.

Apart from saying

through discovery and composition MEF gives you the ability to build applications which will be flexible enough for your every need

I won’t be covering what MEF is or how it works in depth in this post. Instead I recommend checking out the following blogs as well as the MEF site on Codeplex for some great tutorials.

What problem does MEF solve in this application?

The code below shows the Calculate method in the ViewModel.

public void  Calculate()
{
    Calculator calculator = new Calculator();
    Result = calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
}

Notice how Calculator class is created and used within the method. This means there’s no way of changing what class is used for calculations without modifying the code in the ViewModel.

In other words the calculator is tightly coupled to the ViewModel.

Composing, Initializing, Setting up, Bootstrapping, Configuring or whatever you want to call it in MEF

MEF works by using a catalog to discover extensions within assemblies. As the assemblies used in this application are in same XAP we can call the CompositionInitializer SatisfyImports method to automatically configure a container and compose the parts within it.

Looking at the class diagram for the application

we could decide

only the Calculator class will be an composable part
the ViewModel and the Calculator will be composable parts
the CalculatorPage, ViewModel and the class should all be composable parts

As this application only contains a single page we will go with the second option. This means we will be calling the CompositionInitializer SatisfyImport method in the CalculatorPage constructor as shown below

public CalculatorPage()
{
    InitializeComponent();
    CompositionInitializer.SatisfyImports(this);
}

Adding MEF Export Attributes

An export attribute is used to make classes and properties discoverable to the catalog and composable by the container.

As the Calculator class is used by the ViewModel we need to add an Export attribute to it. Because the Calculator implements the ICalculator interface we can use this as the contract type.

[Export(typeof(ICalculator))]
public class Calculator : ICalculator
{
public int Add(int firstValue, int secondValue)
{
    return firstValue + secondValue;
}
}

Similarly as the ViewModel is used by the CalculatorPage it also needs to be decorated with an Export attribute. As no contract is specified, MEF will use the fully qualified name of the type as the contract.

[Export]
public class CalculatorViewModel : INotifyPropertyChanged
{
    .....
}

An important thing to remember is that the export attribute is not allowed on the instance passed to SatisfyImports otherwise you will see the error below

Using MEF Property Imports

To use property imports in MEF we need to add a Calculator property to the ViewModel add decorate it with an Import attribute. In Silverlight MEF requires the property to be public.

[Import]
public ICalculator Calculator { get; set; }

The Calculate method in the ViewModel uses the property like this

public void Calculate()
{
    Result = Calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
}

In the code behind of the CalculatorPage we need to add a CalculatorViewModel property, decorate it with an Import attribute and set it as the data context.

public partial class CalculatorPage : UserControl
{
    [Import]
    public CalculatorViewModel CalculatorViewModel { get; set; }

    public CalculatorPage()
    {
        InitializeComponent();
        CompositionInitializer.SatisfyImports(this);
        DataContext = CalculatorViewModel;
    }
}

If we run the application as it is MEF composes all the parts of the application and we are able to add numbers together… which is good but not great because I don’t recommend you should build applications only using property imports.

Using MEF Constructor Imports

I always try to follow the SOLID design principles whenever I’m developing applications.

The D in SOLID design principles stands for Dependency Inversion Principle.

One of the first things you should be taught when learning test driven development or even good coding practices is how SOLID design principles will help you create applications that are easier to develop, configure, maintain and unit test.

See my blog post ‘How to write better unit tests using RhinoMocks and stubs‘ for an example.

The good news is MEF supports constructor imports.

Using the ImportingConstructor attribute the CalculatorViewModel now takes in a Calculator in its constructor as shown below

[ImportingConstructor]
public CalculatorViewModel(ICalculator calculator)
{
    _calculator = calculator;
    ...
}

and the calculate method uses the calculator like this

public void Calculate()
{
    Result = _calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
}

Take care not to over engineer

So what about the importing the ViewModel in the CalculatorPage? We could stick to using a property for the ViewModel or pass it in the ViewModel constructor (in which case the call to CompositionInitializer SatisfyImports method will have to done in the App.xaml code behind).

I would be inclined to leave it as it is. Because we want to be able to unit test the ViewModel it makes sense to use importing constructors so we stub out the calculator.

Are we ever going to unit test the CalculatorPage? Probably not, and if we do need to, it’s not a major refactoring task.

In any case thanks to MEF the ViewModel can be changed without modifying the code behind for the CalculatorPage.

So what have we achieved?

By using SOLID design principles and MEF we have managed to remove the tight coupling between the ViewModel and the Calculator.

There is a lot of discussion about what MEF is in the development community. Despite numerous claims and comments that it’s not a dependency injection framework, I can’t help thinking it takes a step closer to being one with each release.

The last thing I’ll say about MEF is that

the number of options you have of using MEF is either impressive or confusing depending on what side of the fence you sit on

If you have arrived here from a search engine, this post is part of series about refactoring Silverlight applications.

So if you’re thinking, what if there’s an exception converting a string into an integer, check out the post ‘Validation in Silverlight and WPF using ValidatesOnExceptions‘ which shows one approach in solving this problem using exceptions.