I have a control that does validation on the c开发者_开发百科lient side to show error messages if validation fails prior to doing a postback. In the event that the validation passes, it posts back to the server using __doPostBack:
<script type="text/javascript">
$(document).ready(function () {
$(".save-btn").click(function () {
if (Page_ClientValidate() == false) {
window.scrollTo(0, 0);
$(".error").show();
$(".success").hide();
}
else {
$(".error").hide();
$(".success").hide();
__doPostBack('<%= btnSaveSection.ClientID %>', '');
}
});
});
</script>
In the code-behind, I'm adding an onClick method to that button, as well.
this.btnSaveSection.Click += new System.Web.UI.ImageClickEventHandler(this.btnSaveSection_Click);
For IE and Firefox, __doPostBack works fine, even if I don't set the parameters of __doPostBack. (This is done on several controls, so I had the function in a linked script control and had it as __doPostBack('', '');) After validation, doPostBack causes the ASP.Net code-behind method to be called. But with WebKit browsers (Chrome and Safari), the btnSaveSection_Click method never gets called. In fact, the high-level page (input.aspx) gets a Page_Load event, while the control (section.aspx) doesn't even get that. My current workaround is to put the script in each control and add the button's ClientID which gets it to at least call the control's Page_Load method. From there I can check Page.IsPostBack and parse out the button control from the Page.Request.Form vars.
But I'm forced to think there should be a better way. Anyone have any idea why Firefox/IE work with ASP.Net to call the correct method, but Chrome/Safari don't? Is it a fluke that it works for FF/IE, since it shouldn't work at all without the target being set? I've tested this fairly extensively with .Net 3.5, but the behavior was the same with 4.0.
You should use:
__doPostBack('<%= btnSaveSection.UniqueID %>', '');
as opposed to ClientID.
精彩评论