views:

65

answers:

2

This client side script is being added to buttons in our existing codebase. It basically shows a pop-up that the system is busy whenever a long running process is occuring. this works fine for buttons, however the btn.disabled = true line causes the SelectedIndexChanged event to never fire(when using it on a button, the click even still fires). If I comment out that line, it fires fine. The object is disabled to prevent double clicking. Any ideas on why its not firing? This code is being registered as a client script block, so any changes affect all of the buttons using this code on a page.

@"<script language='javascript' type='text/javascript'>
    function BB(btn, msg, btnID)
 {
         bb1 = new BusyBox('iBB1', 'bb1', 4, '" + ContentImageUrlPath + 
         @"/gears_ani_', '.gif', 125, 147, 207, msg);   
         btn.disabled = true;
         bb1.Show();
         __doPostBack(btnID,'');
         return false;
 }</script>";

Here is the code as seen on the page

<select id="foo" onchange="return BB(this,
'Processing','ddlRoadsAssessment');
setTimeout('__doPostBack(\'foo\',\'\')', 0)" name="foo">
+1  A: 

I can't speculate as to why the event doesn't fire and what to do about that, but maybe you can work with readonly instead of disabled?

Pekka
It looks as though the readonly property still allows a button to be clicked.
Aaron M
+3  A: 

Well yes, if it's disabled, then .NET will assume that it has not changed, and won't even look at the value being posted. You'll have to manually check Request.Form[ddlRoadsAssessment.ClientID] (in, say, OnInit) and compare that to its previous value (which you could store, for instance, in viewstate), and if they don't match, manually invoke a method.

David Hedlund
If that is truly the case, then why does the button.click event still fire when it is set to disabled?
Aaron M
I can't defend why .NET works the way it does in all cases; the best I can hope for is to be able to tell you it does actually work, regardless of what amount (or lack) of discourse that effected the same. A wild guess, tho: when a postback is caused and a button is the sender, it is hard for .NET to deny the fact that it must indeed have been clickable. Other than that, you can easily verify that this is how things work. If you create a `<asp:Textbox id="txt" runat="server" Enabled="false" />`, and change it's value through javascript, then create a postback, you'll be able to ...
David Hedlund
... get `txt.Text == Request.Form[txt.ClientID]` to eval to false.
David Hedlund
is this the way it *ought* to work? no, i guess it's quite weird. a lot of datepickers, for instance, work with a disabled textbox that is changed through a javascript ui. is it the way it *does* work? yes, certainly. although (understandably) only when .NET *knows* that the control is disabled (not when it is being disabled with javascript after the page is rendered)
David Hedlund