trouble validating decimal property with regular expression

Topics: Validation Application Block
Mar 5, 2010 at 10:34 PM

Can a RegExValidator be used on non-string properties?  When I try this:

        [RegexValidator(@"^\[+-]?[\d{0,16}]*\.?\d{0,2}$", MessageTemplate = "Start range must numeric and can be up to 19 digits including 2 decimal points.")]
        public decimal? StartRange { get; set; }

I get the message:
Value to validate is not of the expected type: expected System.String but got System.Decimal instead.

Mar 5, 2010 at 11:16 PM

After reading some posts, it seems RegExValidator only works on strings :-(.

I'll create some self validation then that uses a regex.


Mar 8, 2010 at 12:16 AM

Yes, it would only work on strings as the RegexValidator inherits from ValueValidator<string>.  Another way to do it would be to create your custom regex validator that would convert any object to string before using a regexvalidator.


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

Mar 8, 2010 at 7:58 AM

Making such a validator can be tricky, because you have take localization into account. Do you convert the object according to the current thread culture, the invariant culture or do you specify a culture on the validator itself? When you don't specify this, .NET will use the thread culture by default, which could lead to annoying bugs.

Mar 8, 2010 at 8:21 AM

If localization will be taken into account, the current thread culture should definitely be used.  I'm curious though what are those possible bugs you're anticipating?


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

Mar 8, 2010 at 9:22 AM

Different cultures have a different notations for expressing numbers. Let’s take the imaginary ‘ObjectRegexValidator’ that validates the culture specific string representation of an arbitrary object. When decorated on an Decimal property with the regular expression @"^\[+-]?[\d{0,16}]*\.?\d{0,2}$", the validation will succeed for decimal 12345.67 when ran on a thread with the culture “en-US”, but it will fail when the culture is “nl-NL”, because the Dutch culture will convert that decimal to the string “12345,67” (note the comma).

So when the string conversion is bound to the current thread culture, the validation might fail on certain cultures. While the regular expression can be corrected for this, it is very hard to build a full proof expression that works on all cultures.

So I'd normally go for an CultureInvariant conversion by default, but still it would be hard to communicate to the user what he/she did wrong, because it's not possible to say that the value must contain a dot, because that depends on the culture. The error message must be culture specific to.

Mar 12, 2010 at 2:01 AM

I see your point dot_net_junkie.  I think the way around this is to also localize the regular expression.  The regular expression values must be provided for each culture its going to support.


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.