Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Thanks heaps tvanfosson for the prompt assistance.</p> <p>Ok update:</p> <p>I followed more and more links and eventually found the documentation for "success". The documentation on the plugin's own home page is terrible and omits many key features :) But on the official jQuery page its "better". The "success" option is meant to fire every single time an individual field is successfully validated. So that was working by design and I was wrongly assuming it would only fire when the entire form was valid.</p> <p>I tried your invalidHandler idea. I loved this idea. One issue I came up against was that the ImageButton's postback would still ALWAYS fire off first, so it would start posting back before the invalidHandler code would run. So the postback would still go ahead, then after that, invalidHandler would disable future postbacks, they were firing in the wrong order unfortunately. But apart from that, it showed every other sign of being the perfect solution.</p> <p>I then went the other way trying the submitHandler way, i.e. the inverse. Again, this suffered from some order problems, because the postback would again fire first, but be blocked, then submitHandler would allow future postbacks, but it was already too late, so this postback was missed. You'd have to click the button again twice to get it to go.</p> <p>So the final semi-kludgey solution, that's not too bad to be honest, was:</p> <p>I changed this line to: // Attach client-side validation to the main form $("#&lt;%= form1.ClientID %>").validate({ submitHandler: function() { PreventPostback = false; __doPostBack('UpdatePanel1', ''); } });</p> <p>Which as you can see, first toggles the PreventPostback variable, but then fires off a new postback manually, because the first postback would have already been blocked and died off. So this manual __doPostBack call ensures that a new postback gets fired off respecting the new value of PreventPostback.</p> <p>I removed the event methods from behind the ImageButtons, and made a new method in the server side code called "DoPostBackLogic()" which is only called when the page is posted back, which I know must have been from this validation logic, because that's the only postback that can happen on my form. Then all of the hide/show/save logic happens in there for me. Which means when I am manually calling the __doPostBack, I can simply use the ID of the UpdatePanel and not worry about mimicking a particular ImageButton etc.</p> <p>This way it works perfectly. Postbacks are disabled by default, and when the form is valid, Postbacks are then allowed, but a postback is then manually triggered so that the new value takes effect.</p> <p>So this is essentially your second solution, thanks once again for listening and sharing! :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload