Range Validator Visual Studio Express 2008

**sanjib65** · Dec 16 '09, 12:13 PM

A little bit googling would have solved your problem.

Here goes your code :

Code:

<html>
<body>

<form runat="server">
Enter a date between 2009-12-23 and 2010-03-15:
<br />
<asp:TextBox id="tbox1" runat="server" />
<br /><br />
<asp:Button Text="Submit" runat="server" />
<br /><br />
<asp:RangeValidator
ControlToValidate="tbox1"
MinimumValue="2009-12-23"
MaximumValue="2010-03-15"
Type="Date"
EnableClientScript="false"
Text="The date must be between 2009-12-23 and 2010-03-15!"
runat="server" />
</form>

</body>
</html>

For further reading you can go to =>

404 - Page not found | W3Schools.com

http://www.w3schools.com/aspnet/control_rangevalidator.asp

Sorry! We can't seem to find the resource you're looking for

**Frinavale** · Dec 16 '09, 02:50 PM

Thanks for that Sanjib :)
I didn't know that there was an ASP Classic version of the RangeValidator control!

Since the original poster (chicane) is having problems with the .NET RangeValidator control I figured I'd just add a link to a resource for that control:
RangeValidator Control (General Reference)

-Frinny

**chicane** · Dec 16 '09, 04:57 PM

Hi there
Thanks for your response. I don't think I was clear in my post or I haven't explianed it very well.

You mentioned in your response that the Minimum Value will be 2009/12/23 but this wouldn't be the case if someone submitted the request on a different date, how is the code set so that it works off the Current date that the form is submitted, so that it can be calculated off any date?

Thanks again for your help.

**Frinavale** · Dec 21 '09, 03:44 PM

I would probably just write a JavaScript function that checks the dates.

(Remember that client side validation is easy to get around so you should always do server side validation too).

Call the JavaScript function when you submit the page and have it check if the values are valid. This JavaScript function would use the JavaScript Date Object to make sure that the "to-date" was greater than the "from-date"....if it isn't then the function would return false to cancel the page submit (and maybe display an alert() stating that the page is invalid...or otherwise let the user know that the content is not valid)

How to use JavaScript in ASP.NET

-Frinny

**chicane** · Dec 21 '09, 05:29 PM

Hi

Thanks for getting back to me, I will give it a try shortly and let you know how I get on.

thanks

**YerKiddinMe** · May 13 '10, 06:34 PM

You've got to be kidding...

Javascript? Why are you coding in .Net?
I realize it is too late for the original poster, but put this code in your PageLoad() event :

Code:

            RangeValidator1.MaximumValue = DateTime.Now.AddDays(90).ToShortDateString();
            RangeValidator1.MinimumValue = DateTime.Now.AddDays(-5).ToShortDateString();

This will cause the validator to accept dates between 5 days ago and 90 days in the future.

**Frinavale** · May 13 '10, 07:27 PM

YerKiddinMe,

You're quite right, you should always use server side validation; however, if you want to prevent an unnecessary round trip to the server you can also do client side validation...by this I mean that you can validate something client-side using JavaScript and if it detects that the page is invalid then the JavaScript prevents the page from submitting...di splaying error messages prompting the user to correct the validation errors.

It is easy to get around client side validation so you should always do server side validation as well.

**YerKiddinMe** · May 13 '10, 07:32 PM

Again, why javascript?

VS 2008 validators, by default, run on client side. VS writes the javascript for you.

**Frinavale** · May 13 '10, 08:11 PM

:) exactly why it's so easy to prevent unnecessary round trips to the server :)
However, sometimes you want to customize these and you'll want to write your own JavaScript functions (as is being done in this case....I think...I hope...?)

**YerKiddinMe** · May 13 '10, 08:41 PM

Personally, I never write JavaScript if I don't have to. In this case, two lines of .Net code behind covers the problem of validating a date range based on the current date completely.
Don't sell the built in Validators short, they are quite powerful. The only case where I can see value in writing JavaScript for client side validation in a .Net web application would be if the required range changed based on the values entered in other fields.
If, say, I had a form where I had a drop down list of events and the acceptable date range varied depending on the selected event, JavaScript might be a justifiable choice. But being lazy, I'd probably use the AjaxToolkit to minimize the time cost of the postback, and do the validation server side...more JavaScript that VS will write for me. ;)

**Frinavale** · May 13 '10, 08:55 PM

Ajax in .NET (I'm talking UpdatePanels here) doesn't eliminate any time cost.

It takes the same amount of time as a full page postback and the page undergoes the full ASP.NET life-cycle server side. The only time it saves is rendering in the browser (which is insignificant most of the time).

I agree that it's a lot smoother than a full page postback....but there's no time or resources saved...whereas JavaScript (the validators) do save you the whole process.

I used to be like you.
I hated getting my hands all dirty with JavaScript...an d truth be told I only add it now once I know everything works well on the server and if I had the time.

The more you work in the web environment the more you can appreciate what JavaScript can do for you and how it can make your applications actually more efficient :)

-Frinny

**YerKiddinMe** · May 14 '10, 12:29 PM

It's not a question of "getting my hands dirty with JavaScript", it's a question of efficiency. I won't write JavaScript unless .Net can't do what I need. In the case of the original problem on this thread, VS Validators write client side JavaScript for me, so it is a waste of time to write that JavaScript myself. In the more complex scenario I described, the advantage of hand rolled JavaScript will not be significant unless I have a huge page, slow servers, or thousands of concurrent users.
I've been writing web applications in an enterprise environment for over 4 years, and have found the need to write my own JavaScript maybe 3 or 4 times, and functionality was the reason rather than expensive postbacks. The question becomes "How much more efficient will the application be, and is it worth the loss of efficiancy in coding time?" If I spend even 15 extra minutes making something a half second faster, will my boss think I've spent my time well?

**Curtis Rutland** · May 14 '10, 02:53 PM

Originally posted by YerKiddinMe

It's not a question of "getting my hands dirty with JavaScript", it's a question of efficiency. I won't write JavaScript unless .Net can't do what I need. In the case of the original problem on this thread, VS Validators write client side JavaScript for me, so it is a waste of time to write that JavaScript myself. In the more complex scenario I described, the advantage of hand rolled JavaScript will not be significant unless I have a huge page, slow servers, or thousands of concurrent users.
I've been writing web applications in an enterprise environment for over 4 years, and have found the need to write my own JavaScript maybe 3 or 4 times, and functionality was the reason rather than expensive postbacks. The question becomes "How much more efficient will the application be, and is it worth the loss of efficiancy in coding time?" If I spend even 15 extra minutes making something a half second faster, will my boss think I've spent my time well?

It depends on how scalable your application needs to be. I like the server side code too, because it's much easier to me, but when you have tens of thousands of users, that "half-second" starts to add up, but not just in time saving, but in bandwidth/server resource utilization as well. Why make unnecessary postbacks? If you can prevalidate your stuff using a JS method, that's several postbacks saved, which when scaled to lots of users, is a considerable amount.

I think it's best to use the best tool for the job. When it comes to prevalidating your inputs, Javascript is significantly more efficient than trips back to the server.

**YerKiddinMe** · May 14 '10, 04:10 PM

"When it comes to prevalidating your inputs, Javascript is significantly more efficient than trips back to the server."

I agreed to that several posts ago. It is also much more efficient to use the built-in .Net Validators, which, by default, write client side Javascript, thus still saving the trip to the server, while also saving me from having to write the JavaScript myself. That was my original point, and I apologize for getting sidetracked with trivial details not germane to the original post.
[...he said before continuing down the side track...]

Hand coded JavaScript is a good choice for validation code ONLY in rare circumstances. I'm not arguing against client side validation, I'm arguing against custom writing it yourself when .Net will do it for you. When your validarion requirements are so complex that .Net validation will require a postback, there are many factors to consider before choosing either route.

As you mentioned, how scalable does it need to be is one question, but the size of the page makes a big difference, too. A small form with five or ten input fields is a lot less load than the form I am working on now with nearly 250 controls on it, and also less likely to fail validation.

I'm not saying JavaScript is never the best choice. First that would just be wrong, and second I already mentioned above, I DO use it when I NEED it. But to say home-rolled JavaScript is always the best choice is also wrong.

Range Validator Visual Studio Express 2008

Range Validator Visual Studio Express 2008

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment