Diego Marcet

It’s been a long time since my last post!

Way back in June I wrote a small post about getting familiarized with Composite Application Guidance for WPF (Prism). And all this time I have been working on the next version of the guidance: Composite Application Guidance for WPF and Silverlight which will be released in the very near future (in the meantime you can check the latest Drop!).

We faced lots of technical challenges during the development process, and one of them was the differences that exists on Validation between WPF and Silverlight. You can read about this with more detail on Bob’s post, on the Validation in the Reference Implementation section. What I’d like to talk about today is on a different approach we tried on that time, relying on the VisualStateManager for the UI feedback when a validation error occurs.

For this purpose I created a small Silverlight solution with a single view:

As you may notice my designing skills haven’t improved

The scenario for this sample application is a validation that occurs when entering an integer into the TextBox: if it is smaller than 0 or larger than 100, or not a number a validation error will occur, when that happens the TextBox’s background will turn red. If after this, a valid number is set, the background will go back to white. Now let’s dig into the details!

The implementation of this functionality is very similar to what we did on Prism-v2 (again I recommend you to read Bob’s post for more details on this), but instead of declaring an Attached Property for the color of the Background, I created an attached property with a flag that will enable or disable the UI feedback when a validation error occurs:

When set to true for the first time, the ChangeStateOnError property will trigger the creation of the behavior that will monitor the validation errors on the TextBox (through the BindingValidationError event) and the behavior that will change the state on the VisualStateManager for the TextBox:

Now, the ChangeStateBehavior is attached to the TextBox, this means that the behavior will listen to changes on the Errors attached property (which is maintained by the monitoring behavior) and whenever the collection changes the state will be re-set.

This allows for adding other behaviors that respond to this validation error, as in Prism-v2 current approach.

Finally the visual states must be defined on the style applied to the TextBox (in this sample ValidatedTextBoxStyle). Here the states names are hardcoded on the behavior to: ErrorOn and ErrorOff, but of course new attached properties could be set to specify the names of the states to switch.

The benefit with this approach is that the UI feedback can be worked separately by a designer, using Blend for instance, in a more flexible way than if an attached property were set for each change on the UI when a validation error occurs. The negative side of this is that the designer experience on Visual Studio is not very friendly for declaring the states on the style, although this can be easily achieved with Blend

You can get the source code of the sample application here.