Regex.IsMatch help

[Guest]

I need to determine whether a text box contains a value that does not convert
to a decimal. If the value does not convert to a decimal, I want to throw a
MessageBox to have the user correct the value in the text box. I have the
following code but when the user enters a decimal value the Regex.IsMatch
catches it (ex. 250.50 should be allowed, but 250.50.0 should not). My code
is as follows:

if( ! Regex.IsMatch( tboxQtyCounted.Text, "^([0-9]*)$" ) )
MessageBox.Show("Invalid Value! Please enter a valid integer or
decimal value.")

 

[Jon Skeet [C# MVP]]

I need to determine whether a text box contains a value that does not convert
to a decimal. If the value does not convert to a decimal, I want to throw a
MessageBox to have the user correct the value in the text box. I have the
following code but when the user enters a decimal value the Regex.IsMatch
catches it (ex. 250.50 should be allowed, but 250.50.0 should not). My code
is as follows:

if( ! Regex.IsMatch( tboxQtyCounted.Text, "^([0-9]*)$" ) )
MessageBox.Show("Invalid Value! Please enter a valid integer or
decimal value.")

Well, you could make it use something like [0-9]*\.+[0-9]*, but
personally I'd be tempted to go for hard-coding the test by going
through the string - it's easy to write, and easy to understand.

Unfortunately, the regex above matches "." - if you didn't mind
disallowing ".5" you could change the first * to a + to avoid this. Of
course it would be possible to improve it further, but as the
expression gets more and more complicated, it gets less and less
readable

 

[Oliver Sturm]

Well, you could make it use something like [0-9]*\.+[0-9]*, but
personally I'd be tempted to go for hard-coding the test by going
through the string - it's easy to write, and easy to understand.

Unfortunately, the regex above matches "." - if you didn't mind
disallowing ".5" you could change the first * to a + to avoid this. Of
course it would be possible to improve it further, but as the
expression gets more and more complicated, it gets less and less
readable

Well, I'm not going to have this discussion again Just wanted to
mention a few things:

- When trying to find out whether a value will make a good decimal number, why not just try to convert it into one and see if that works? You could use the Parse or the TryParse methods on the Single, Double or Decimal structs, depending on your needs and your framework version.

- A proper expression for your purpose might look like this:

^\d*(\.\d+)?$

This matches "3", "4.7" and ".9", but not "1.2.3", ".", "7." or other
funny stuff - only decimal numbers in a common simple syntax.

Now, another thing that you miss (Jon) is the reusability aspect of
regular expressions. For example, if you wanted to find a regex for a more
complicated syntax, like the one involving exponential parts of the
number, you could just search one of the many regex libraries on the net,
like here:

http://www.regexlib.com/Search.aspx?k=decimal number


Oliver Sturm

 

[Guest]

Thanks to both! I am new to C# and just learning about Regular Expressions.
I appreciate Jon's concern in regards to readability because a new guy like
myself has a hard time understanding the Regular Expression syntax. In fact,
I really don't understand it very well at all. Can you point me to a source
that would teach me the essentials of the Regular Expression syntax?

When I try to implement the expression, I get an error that states -
unrecognized escape sequence. I looked at the Microsoft documentation but I
can't figure out what I'm doing wrong.

Well, you could make it use something like [0-9]*\.+[0-9]*, but
personally I'd be tempted to go for hard-coding the test by going
through the string - it's easy to write, and easy to understand.

Unfortunately, the regex above matches "." - if you didn't mind
disallowing ".5" you could change the first * to a + to avoid this. Of
course it would be possible to improve it further, but as the
expression gets more and more complicated, it gets less and less
readable

Well, I'm not going to have this discussion again Just wanted to
mention a few things:

- When trying to find out whether a value will make a good decimal number, why not just try to convert it into one and see if that works? You could use the Parse or the TryParse methods on the Single, Double or Decimal structs, depending on your needs and your framework version.

- A proper expression for your purpose might look like this:

^\d*(\.\d+)?$

This matches "3", "4.7" and ".9", but not "1.2.3", ".", "7." or other
funny stuff - only decimal numbers in a common simple syntax.

Now, another thing that you miss (Jon) is the reusability aspect of
regular expressions. For example, if you wanted to find a regex for a more
complicated syntax, like the one involving exponential parts of the
number, you could just search one of the many regex libraries on the net,
like here:

http://www.regexlib.com/Search.aspx?k=decimal number


Oliver Sturm

 

[Guest]

I did a little more searching and found the answer to my unrecognized escape
sequence (i.e. @). Anyway, I would really appreciate some direction as to an
educational source on RegEx. Thanks!!!

Well, you could make it use something like [0-9]*\.+[0-9]*, but
personally I'd be tempted to go for hard-coding the test by going
through the string - it's easy to write, and easy to understand.

Unfortunately, the regex above matches "." - if you didn't mind
disallowing ".5" you could change the first * to a + to avoid this. Of
course it would be possible to improve it further, but as the
expression gets more and more complicated, it gets less and less
readable

Well, I'm not going to have this discussion again Just wanted to
mention a few things:

- When trying to find out whether a value will make a good decimal number, why not just try to convert it into one and see if that works? You could use the Parse or the TryParse methods on the Single, Double or Decimal structs, depending on your needs and your framework version.

- A proper expression for your purpose might look like this:

^\d*(\.\d+)?$

This matches "3", "4.7" and ".9", but not "1.2.3", ".", "7." or other
funny stuff - only decimal numbers in a common simple syntax.

Now, another thing that you miss (Jon) is the reusability aspect of
regular expressions. For example, if you wanted to find a regex for a more
complicated syntax, like the one involving exponential parts of the
number, you could just search one of the many regex libraries on the net,
like here:

http://www.regexlib.com/Search.aspx?k=decimal number


Oliver Sturm

 

[Jon Skeet [C# MVP]]

Well, you could make it use something like [0-9]*\.+[0-9]*, but
personally I'd be tempted to go for hard-coding the test by going
through the string - it's easy to write, and easy to understand.

Unfortunately, the regex above matches "." - if you didn't mind
disallowing ".5" you could change the first * to a + to avoid this. Of
course it would be possible to improve it further, but as the
expression gets more and more complicated, it gets less and less
readable

Well, I'm not going to have this discussion again Just wanted to
mention a few things:

- When trying to find out whether a value will make a good decimal
number, why not just try to convert it into one and see if that
works? You could use the Parse or the TryParse methods on the Single,
Double or Decimal structs, depending on your needs and your framework
version.

Yes, as there's TryParse, that's a good thing to use (it also means you
don't need to worry about allowing negatives - something we haven't
mentioned yet).

Again, a simpler solution than using regular expressions

If it has to be *really* fast (i.e. it's definitely an application
bottleneck) a hard-coded check is much faster (at least last time I did
some benchmarking) but for actual user input, efficiency probably
wasn't an issue.

- A proper expression for your purpose might look like this:

^\d*(\.\d+)?$

This matches "3", "4.7" and ".9", but not "1.2.3", ".", "7." or other
funny stuff - only decimal numbers in a common simple syntax.

I was assuming that "7." would be allowed (as it is by Double.Parse).
The OP really needs to work out exactly what he wants to allow

Now, another thing that you miss (Jon) is the reusability aspect of
regular expressions. For example, if you wanted to find a regex for a more
complicated syntax, like the one involving exponential parts of the
number, you could just search one of the many regex libraries on the net,
like here:

http://www.regexlib.com/Search.aspx?k=decimal number

That's true. Of course, you have to make sure you use the right dialect
of regular expressions - expressions that will work in .NET may not
work in Java and vice versa. (As far as I can see, that site doesn't
say which dialect any particular expression is designed for.)

Of course, the hard-coded check would also be reusable...

 

[Oliver Sturm]

Yes, as there's TryParse, that's a good thing to use (it also means you
don't need to worry about allowing negatives - something we haven't
mentioned yet).

Again, a simpler solution than using regular expressions

If it has to be really fast (i.e. it's definitely an application
bottleneck) a hard-coded check is much faster (at least last time I did
some benchmarking) but for actual user input, efficiency probably
wasn't an issue.

I guess the speed difference could be partly due to the fact that you'd
code your own check more along the lines of your actual requirements,
while the Parse/TryParse methods include support for several formats, plus
culture specific things. Or were you saying they are badly coded?

I was assuming that "7." would be allowed (as it is by Double.Parse).
The OP really needs to work out exactly what he wants to allow

True. The "7." syntax doesn't add anything to the functionality though, so
I wouldn't see the purpose of supporting it.

That's true. Of course, you have to make sure you use the right dialect
of regular expressions - expressions that will work in .NET may not
work in Java and vice versa. (As far as I can see, that site doesn't
say which dialect any particular expression is designed for.)

This is usually only a problem with rather complicated stuff like zero
width assertions and similar things, where the syntax varies over
platforms. Actually, there's a POSIX standard for regular expressions -
but it's verbose and ugly, so it's not nice writing expressions to conform
with it.

When looking at such a library, it's probably best to find out what people
are focused on, so you can guess for which platform they're writing their
expressions. For example, if they're advertising Regulator on the front
page, .NET isn't too wild a guess ;-)

Of course, the hard-coded check would also be reusable...

I'd rather give someone a good regex - the problem of passing around code
snippets that do these kinds of checks is not the passing around in
itself. It's more the making small changes to adapt to the target
application that quickly breaks things.

Of course regexes break, too. But it's easy to post to a newsgroup with
your regex and a few sample inputs and get a good reply quickly. I like to
read posts like that, because they tend to be short and to the point. It's
much harder posting a complete code snippet with sample inputs in the
first place, and it's much harder to read such a post and help that person.


Oliver Sturm

 

[Oliver Sturm]

I did a little more searching and found the answer to my unrecognized
escape
sequence (i.e. @). Anyway, I would really appreciate some direction as to
an
educational source on RegEx. Thanks!!!

I recently saw this: http://www.regular-expressions.info/tutorial.html

They are a little bit biased towards RegexBuddy as a tool while there are
lots of other tools around (I use Regulator although it has a few bugs in
the editor), but the content of the tutorial looks good. Just search
Google for more stuff - regular expressions have been around for about
fifty years, there's enough information available.



Oliver Sturm

 

[Jon Skeet [C# MVP]]

I guess the speed difference could be partly due to the fact that you'd
code your own check more along the lines of your actual requirements,
while the Parse/TryParse methods include support for several formats, plus
culture specific things. Or were you saying they are badly coded?

I suspect it's that TryParse tries to parse it as it goes, whereas the
hard-coded check *only* checked for validity - so no time is wasted
doing actual parsing of invalid data.

I wouldn't like to say for sure though - all I have to go on is my
benchmarks from a while ago. Things might have improved in .NET 2.0 of
course.

True. The "7." syntax doesn't add anything to the functionality though, so
I wouldn't see the purpose of supporting it.

I guess it depends what the OP wants. It's not terribly hard to support
"7." in either solution though - it's not a significant issue IMO.

This is usually only a problem with rather complicated stuff like zero
width assertions and similar things, where the syntax varies over
platforms.

True. For anything even slightly complicated I'd want to pick it apart
though, and check that everything really would work in the appropriate
platform.

Actually, there's a POSIX standard for regular expressions -
but it's verbose and ugly, so it's not nice writing expressions to conform
with it.

And in particular I doubt that either the .NET or Java implementation
is conformant

When looking at such a library, it's probably best to find out what people
are focused on, so you can guess for which platform they're writing their
expressions. For example, if they're advertising Regulator on the front
page, .NET isn't too wild a guess ;-)

Well, that only shows what the *owner* of the site is focused on -
there's nothing to say that the people submitting regular expressions
are working on that platform...

I'd rather give someone a good regex - the problem of passing around code
snippets that do these kinds of checks is not the passing around in
itself. It's more the making small changes to adapt to the target
application that quickly breaks things.

At that point you're not really reusing with either form though.

Of course regexes break, too. But it's easy to post to a newsgroup with
your regex and a few sample inputs and get a good reply quickly.

And bad replies too, of course. It's quite easy to have something
subtle broken in a regular expression that can fool people - I've seen
it happen.

I like to
read posts like that, because they tend to be short and to the point. It's
much harder posting a complete code snippet with sample inputs in the
first place, and it's much harder to read such a post and help that
person.

If the code snippet gets long enough that it's difficult to post, I
suspect that regular expressions would usually win on the simplicity
front anyway though. As I've said several times, I'm not against
regular expressions in principle - just against using them in all
situations. This one is a border-line case for me.