it is a nice article but i have problem javascript date validation when i submit the button it validating but when i click the javascript popup ok it is post backing and insering record Db even wrong Valid Date.

Can u some one help me pls asap.

UseSubmitBehavior="false" on the button will append some code to the onclick javascript that is rendered to force it to use the __dopostback .net javascript event.

Hey, I came up with a similar solution. Let me know what you think: http://thecodebug.com/?p=33

It can be done this way:

function btnSubmitClicked(t) {
<%=Page.GetPostBackEventReference(btnSubmit as Control)%>;
t.disabled = true;
}

...

Problem:
To prevent multiple submits.

Note.
After Submit button is clicked the client side code and server side code is executed in following sequence:
a) Client side event OnClientClick (and javascript function calling), and then OnClick event which performs Post Back.
b) Server side method Page_Load(...), and then method btnSubmit_Click(...).
It is normally.
If javascript function sets btnSubmit.disabled=true; then the event handler btnSubmit_Click(...) on the server side is not being evoked. The reason is: disabled button cannot be clicked.

Solution.
Change the sequence of performing operations on the client side:
At first do postback when button is not disabled.
And then disable the button. Button will remain disabled till page is rerendered.

It can be done this way:

...

OnClick="btnSubmit_Click"
OnClientClick = "btnSubmitClicked(this)"
Text= ...
...

thanks you it works

Hi,
This is nice article.

as i have written another javascript function for the same button for validationg the input fields, and also written this method to disable the button. in this case, the javascript which is written for validations is not working.

Can you please help me in this regard

Thanks
Ravikrishna

Thank you so much, it really helped

protected override void Render(HtmlTextWriter writer)
{
ClientScript.RegisterOnSubmitStatement(typeof(string), "DisableButton", "buttonToDisable.disabled = true;");
base.Render(writer);
}

Saludos.

I've had problems with this technique when the page also contains an UpdatePanel (.NET 2.0. Don't ask).

In my case the submit button is outside of the UpdatePanel; the UpdatePanel exists only because it contains a dropdown that must change the controls available on the page via an async postback.

The problem I was having was that Page_ClientValidate() was breaking the UpdatePanel; that is to say the next change of the dropdown after the submit button was pressed with invalid entries on the page resulted in no async postback by the UpdatePanel. The second dropdown change did work. Very odd.

I used Reflector to look at WebUIValidation.js in System.Web.dll and found that it modifies a variable called Page_BlockSubmit. This variable appears to, er, block submissions! Good name that, really ...

So, in my version of this JavaScript, if Page_ClientValidate() returns false then I set Page_BlockSubmit to false and then return false (which stops submission anyway).

The UpdatePanel now works. Validation failures stop page submission. The button is disabled when the page is valid and a postback occurs.

Job done. But not quickly ...!

Very Nice article. Wasted so many times. Your article has given very gr8 energy to me.

BUTTON ASP.NET XML
asp:Button ID="btnFinish" Text="Finish" OnClick="btnFinish_Click" OnClientClick="window.setTimeout('disableFinishButton()',0); return true" runat="server"

JAVASCRIPT
script type="text/javascript"
function disableFinishButton()
{
var arrInputs = document.getElementsByTagName('INPUT')

for (var i = 0; i < arrInputs.length; i++)
{
if (arrInputs[i].getAttribute('id') != null)
{
if (arrInputs[i].getAttribute('id').indexOf('btnFinish') > -1)
{
arrInputs[i].disabled = true
break
}
}
}
}
script

Works for me with only a few lines of code

The settings page allows one to choose between two "disabling methods" 70-649 exam.

The default method, "Use a flag variable...", works in all browsers 70-291 exam.

The other method, using HTML's "disabled" attribute, for some mysterious reason don't work in my Internet Explorer. I can't debug it, because I'm running IE under Wine 640-863 exam and it's cumbersome, so just don't choose this disabling method 350-030 exam. I leave it there for some developer who runs Windows and wants to fix it.

If you use this code:

protected void btnSubmitAsync_Click(object sender, EventArgs e){
//beep .. this is my modification
System.Media.SystemSounds.Beep.Play();
// simulate load on the web server for 2 seconds.
System.Threading.Thread.Sleep(2000);
// set textbox to the current date/time so we can verify things are working correctly.
txtDateSubmitAsync.Text = DateTime.Now.ToString();
}

When you make double clik to btnSubmitAsync button, you can hear, that FireFox post it twice.

Any idea? I have FireFox version .0.11. In IE works good.

Great article....Thanks...

Right, I've now got this working with ValidationGroups by passing the group name to the Page_ClientValidate() method like this: Page_ClientValidate('validationgroup')

If like me you are registering the client script server side using ClientScript.RegisterClientScriptBlock(), you will need to register a separate script for each validation group. This caught me out at first as I use a helper routine, calling it for each button that I wanted the "click once" functionality applied to. This helper registers the client script, but because the "key" parameter was the same each time, only the first one got registered (with whatever ValidationGroup happened to be on that button). I got around this by including the ValidationGroup name in the RegisterClientScriptBlock() "key" parameter, ensuring that a separate client script is registered for each validation group. My complete helper routine is as follows:-

public static void ForceSingleButtonClick(Page page, Button button)
{
const string StyleName = "disabled_button";

string scriptKey = "clickoncebtn" + button.ValidationGroup;

if (!page.ClientScript.IsClientScriptBlockRegistered(scriptKey))
{
// Register script (use both IE and FF class attribute names).
StringBuilder sb = new StringBuilder();
sb.Append(" function disableButtonOnClick(oButton)");
sb.Append(" {");
sb.Append(" if (typeof(Page_ClientValidate) == 'function') ");
sb.AppendFormat(" if (Page_ClientValidate('{0}') == false) return false; ", button.ValidationGroup);
sb.Append(" oButton.disabled = true; ");
sb.AppendFormat(" oButton.setAttribute('className', '{0}'); ", StyleName);
sb.AppendFormat(" oButton.setAttribute('class', '{0}');", StyleName);
sb.Append("}");

// Register a separate script for each validation group.
page.ClientScript.RegisterClientScriptBlock(
typeof(WebUtility),
scriptKey,
sb.ToString(),
true);
}

// Alter button click to call javascript before normal postback.
button.UseSubmitBehavior = false;

PostBackOptions options = new PostBackOptions(button);

button.OnClientClick =
"disableButtonOnClick(this); " +
page.ClientScript.GetPostBackEventReference(options) + "; return;";
}

Hope this helps someone! I would be interested to hear of any problems etc.
Andy (andrew.stephens@cheshire.gov.uk)

Sorry, I should have said that I was referring to my first comment regarding firing of validators, rather than the author's original code above.

Andy

I've just found that this won't work when controls have their ValidationGroup property set. The button will fire all validators regardless of whether they are in the same ValidationGroup or not. As yet I haven't found a fix. Anyone have any ideas?!

Andy

Thanks Andy. I didn't even notice the issue. Glad you found it before I implemented this into production. Funny that you posted on the very day I found this great article.

This does not work when there are validator controls on the page. To fix this, add the following lines to the start of the javascript function (before the line 'oButton.disabled = true;'):

if (typeof(Page_ClientValidate) == 'function')
if (Page_ClientValidate() == false)
return false;

Also, I have found intermittent problems with the button's server-side click event handler firing twice (it seems to happen on our production server where the postback round-trip takes longer than on my dev PC). To fix this, add a "return" to the end of the button's OnClientClick property:

btnSubmit.OnClientClick = "disableButtonOnClick(this, 'Please wait...', 'disabled_button'); ";
btnSubmit.OnClientClick += ClientScript.GetPostBackEventReference(optionsSubmit);
btnSubmit.OnclientClick += "; return;";

Hope this helps someone

Andy

nice article, thanks!