krisgibson
New Member
Hi, I have a form which I have put a RegularExpressionValidator on. It has a pattern of d{3} which means just that it should contain 3 numbers. In javascript or even vbscript it would not match on a blank field. In my asp.net form it does not throw an error if the field is left blank. How can I get it to do this? Do I need to have two validations per form field, one (RequiredFieldValidator) to check if it's empty, and a second (RegularExpressionValidator) to check if it's the correct format?<BR><BR>Thanks.Exactly, use two validation controls: the RequiredFieldValidator and the RegularExpressionValidator. Also, if you are wanting the text box to contain JUST three digits, you need to do:<BR><BR>^d{3}$<BR><BR>If you leave off the ^ and $, values like: Scott999 would be valid.Darn, that sure does seem stupid to have to use 2 seperate controls. Thanks for your time.Makes perfect sense to me. The only way you could do it with one validation control would be to have the regular expression validator report that the entry was NOT valid if the user entered a blank string. If this was the case, then you couldn't use RegularExpressionValidators for textboxes that were optional. And if that were the case, there would be plenty of people saying: "seems pretty stupid to not be able to use a RegularExpressionValidator on an optional form field." 
While I do agree with you to some extent, I am just used to it depending on the pattern that you use. For example, this pattern ^d{3}$ would mean that it would have to match 3 numbers. It would take into consideration if it was blank or not. It would return that it does not match if the field was empty. However, this pattern ^(d{3})?$ would make it so that you can leave it blank and it will match, or you can enter 3 numbers. Do you get what I mean? I just wish that it was entirely dependent on the pattern, as opposed to being based on if it was blank or not and then the pattern. I think that makes sense, you can use this site, http://builder.cnet.com/webbuilding/pages/Programming/Scripter/050698/toolrei.html, to test the above patterns using javascript. I think that made sense and that I got my point across.That makes perfect sense. Yes, that would have been nice, but I still like the way they did it. Your average ASP.NET developer is not going to be a regex superstar, and might forget the ? (or accidentally add it) and then be scratching their heads for a long while not comprehending what happened. Also, allowing for the regex validation control to FORCE a required field entry kind of makes the RequiredFieldValidator not really needed, right? In essence, it reduces the orthogonality of the language (and, according to folks who know way more about programming language theory than I do, "good" languages are highly orthogonal).
While I do agree with you to some extent, I am just used to it depending on the pattern that you use. For example, this pattern ^d{3}$ would mean that it would have to match 3 numbers. It would take into consideration if it was blank or not. It would return that it does not match if the field was empty. However, this pattern ^(d{3})?$ would make it so that you can leave it blank and it will match, or you can enter 3 numbers. Do you get what I mean? I just wish that it was entirely dependent on the pattern, as opposed to being based on if it was blank or not and then the pattern. I think that makes sense, you can use this site, http://builder.cnet.com/webbuilding/pages/Programming/Scripter/050698/toolrei.html, to test the above patterns using javascript. I think that made sense and that I got my point across.That makes perfect sense. Yes, that would have been nice, but I still like the way they did it. Your average ASP.NET developer is not going to be a regex superstar, and might forget the ? (or accidentally add it) and then be scratching their heads for a long while not comprehending what happened. Also, allowing for the regex validation control to FORCE a required field entry kind of makes the RequiredFieldValidator not really needed, right? In essence, it reduces the orthogonality of the language (and, according to folks who know way more about programming language theory than I do, "good" languages are highly orthogonal).