CausesValidation is set to “False” but the client side validation is still firing


I have several RequiredFieldValidators in an ASP.NET 1.1 web application that are firing on the client side when I press the Cancel button, which has the CausesValidation attribute set to "False". How can I get this to stop?

I do not believe that Validation Groups are supported in 1.1.

Here's a code sample:

<asp:TextBox id="UsernameTextBox" runat="server"></asp:TextBox>
<br />
<asp:RequiredFieldValidator ID="UsernameTextBoxRequiredfieldvalidator" ControlToValidate="UsernameTextBox" 
runat="server" ErrorMessage="This field is required."></asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="UsernameTextBoxRegExValidator" runat="server" ControlToValidate="UsernameTextBox"
Display="Dynamic" ErrorMessage="Please specify a valid username (6 to 32 alphanumeric characters)." 
ValidationExpression="[0-9,a-z,A-Z, ]{6,32}"></asp:RegularExpressionValidator>

<asp:Button CssClass="btn" id="addUserButton" runat="server" Text="Add User"></asp:Button>
<asp:Button CssClass="btn" id="cancelButton" runat="server" Text="Cancel" CausesValidation="False"></asp:Button>

Update: There was some dynamic page generating going on in the code behind that must have been messing it up, because when I cleaned that up it started working.


Validation Groups were not added to ASP.NET until version 2.0. This is a 1.1 question.

Double check your setting and make sure you are not overwriting it in the code behind.

By : dbugger

Are they in separate validation groups (the button and validator controls)?

You're not manually calling the JS to do the client validation are you?

"I'm trying to drive in a nail. Should I use the heel of my shoe or a glass bottle?"

Both Stored Procedures and ORMs are difficult and annoying to use for a developer (though not necessarily for a DBA or architect, respectively), because they incur a start-up cost and higher maintenance cost that doesn't guarantee a pay-off.

Both will pay off well if the requirements aren't expected to change much over the lifespan of the system, but they will get in your way if you're building the system to discover the requirements in the first place.

Straight-coded SQL or quasi-ORM like LINQ and ActiveRecord is better for build-to-discover projects (which happen in the enterprise a lot more than the PR wants you to think).

Stored Procedures are better in a language-agnostic environment, or where fine-grained control over permissions is required. They're also better if your DBA has a better grasp of the requirements than your programmers.

Full-blown ORMs are better if you do Big Design Up Front, use lots of UML, want to abstract the database back-end, and your architect has a better grasp of the requirements than either your DBA or programmers.

And then there's option #4: Use all of them. A whole system is not usually just one program, and while many programs may talk to the same database, they could each use whatever method is appropriate both for the program's specific task, and for its level of maturity. That is: you start with straight-coded SQL or LINQ, then mature the program by refactoring in ORM and Stored Procedures where you see they make sense.

This video can help you solving your question :)
By: admin