ASP.NET 2.0 clientvalidationfunction Firing When it Shouldn't

  • Thread starter Thread starter mwieder
  • Start date Start date
M

mwieder

I've got an ASP.NET form with a textbox and a customvalidator. The
form inherits from a base wizard class with back, next and cancel
buttons. The CausesValidation property of the Cancel button gets set
to false, yet the javascript clientvalidationfunction is firing when
the cancel button is hit. Running through the debugger, the
CausesValidation property is set to false on the Page_Load of the
derived form. Why is the clientside javascript firing even though
causesvalidation is false? How do I stop this?
 
Hello,

Please do a view source and paste that buttons onclick code here so we
can be sure its doing client side validation. You will see a
Page_ClientValidate() call on the onclick if it is. Also overload
OnPreRender() and make sure CausesValidation is not changed. I'd like
to see that html mentioned above if you care to post it.

-sam
 
It just occured to me to make sure you have CausesPostback of that
button set to false.

-sam
 
Here is the relevant code form the 'view source':
<script language="javascript">
<!--
function OnPasswordValidate(source, arguments) {
arguments.IsValid = pwd1.value == pwd2.value;
}
// -->



<td colspan="2"><input name="_ctl_AuthPage:_ctl22:tbxPassword"
type="password" id="_ctl_AuthPage__ctl22_tbxPassword" tabindex="5"
class="TextBox" style="width:350px;" /></td>
<td align="right"><span id="_ctl_AuthPage__ctl22_pwdCustomValidator"
title="Password must contain at least 6 characters"
evaluationfunction="CustomValidatorEvaluateIsValid"
clientvalidationfunction="OnPasswordValidate"
style="color:Red;visibility:hidden;"><img align='absmiddle'
src='/proCube/images/err.gif'/></span></td>



<a id="_ctl_AuthPage__ctl22__btnCancel" style="MARGIN-LEFT: 10px"
class="Button" tabindex="204" direct="true"
href="javascript:__doPostBack('_ctl_AuthPage$_ctl22$_btnCancel','')">Cancel</a></td>
 
----
<a id="_ctl_AuthPage__ctl22__btnCancel" style="MARGIN-LEFT: 10px"
class="Button" tabindex="204" direct="true"
href="javascript:__doPostBack('_ctl_AuthPage$_ctl22$_btnCancel','')">Cancel­</a></
----
Client side validation is not happening here. It is happening on the
server. Look closely and you should notice the form posting back when
you press 'Cancel'.

Try setting CausesPostBack to false and see if that fixes it.

-
Sam
 
Client side validation is happening - when I hit the cancel button, it
never makes it back to the server - the OnPasswordValidate method is
executed and it short circuits the call back to the server. We do want
the cancel button to post back to the server, we just don't want the
client side validation function to execute on cancel.
 
Here's more info. Setting it to not postback to the server doesn't
help - also the error message displayed is only exists in the cleint
side code, so I know it is hitting the client side validation. I put a
break point in the clientside validation method and it got hit as well.
The stack is:
__doPostBack
common_newPostback
Page_ClientValidate
ValidatorValidate
CustomValidatorEvaluateIsValid
OnPasswordValidate

How do I stop the client validation from happening here?
 
Here's more info. Setting it to not postback to the server doesn't
help - also the error message displayed is only exists in the cleint
side code, so I know it is hitting the client side validation. I put a
break point in the clientside validation method and it got hit as well.
The stack is:
__doPostBack
common_newPostback
Page_ClientValidate
ValidatorValidate
CustomValidatorEvaluateIsValid
OnPasswordValidate

How do I stop the client validation from happening here?
You can set the CausesValidation property for the button to false.
 
hm... quoting from my initial post:
"The CausesValidation property of the Cancel button gets set
to false,"
 
This 'common_newPostback' - did you write that javascript? That's
where the problem is. ASP.Net 1.1 does not have any such function in
__doPostback. In regular asp.net, __doPostback basically just does a
form submit.

I'm afraid its your own client side javascript code that isn't doing
what you want. You'll have to see who rewrote __doPostBack and how to
fix it.

-Sam
 
BTW, there's a chance that __doPostBack has been rewritten in asp.net
2.0 to do this common_newPostback, altho i googled it and didn't get
any hits. If that's the case, could you tell me? It would be a new
thing to learn about 2.0.

-Sam
 
Back
Top