Parameterize ValidationRule in WPF

Question

I've only scraped the surface of validation in WPF and have come across a scenario that is likely fairly common: I have a TextBox whose value needs to be validated against a variable data type, depending on the context. For example, if the context's data type is 'int,' then the TextBox needs to accept only input that can be converted to an Int32.

My first thought was to inherit from the ValidationRule class and to include the context and to use a switch inside the overridden Validate function, but I am unable to bind anything to it since it is not a FrameworkElement.

Any thoughts?

Answer 1

You can expose IDataErrorInfo. This lets you do data validation with complex logic.

Answer 2

Personally I don't like using IDataErrorInfo for something this simple because it requires a gratuitous creation of a ViewModels and a lot of extra code where none should be necessary. It should be as simple as this:

I have a markup extension that allows me to create a binding with custom validation code specfied as a C# expression. This is extremely simple to do, except for the C# parser: Just implement ProvideValue() by constructing a MultiBinding that uses a converter and builds the appropriate validation structure. This allows the validation expression to receive the containing DataContext and the user-specified Binding object in addition to the value being validated.

With this solution coded, you can do something like this:

BoundProperty="{my:ValidatedBinding
  Path=SomeProperty,
  ValidationExpression = context is TextBox ? (int)value>3 : (int)value<7,
  Mode=TwoWay,
  Converter=...

You could easily adapt my solution without the C# parser by creating the expression as a lambda in the code-behind and referencing it with x:Static:

public static reaonly Expression myValidatorExpression =
  (object value, object context, BindingBase binding) =>
    context is TextBox ? (int)value>3 : (int)value<7;

...
  ValidationExpression={x:Static local:MyClass.myValidatorExpression}

In general I find this technique easier and clearer than using ViewModels. I still use ViewModels when there is a complex transformation needed, otherwise just pure XAML straight to the business objects layer.

Note that this approach assumes your business objects layer is not tied to any particular the back-end storage layout (eg SQL table structure). If it were, changing the back-end storage would require changing my UI and this would not be desirable either, so a ViewModel would be desirable from that standpoint. But if not, I always prefer to keep it simple and just use straight XAML.