It seems that the problem is that setting the selection in a <select> element programmatically does not fire the onchanged event:

onchange Event

This is true even without all to goo to select the item -- I tried it with a simple listbox and a button that selected the third item, and same deal.

I don't offhand have a know of a way to get around this ... it seems to be a limitation in the IE object model. It might be possible to somehow force a postback when the selection is changed, but I haven't been successful in getting that to happen. If I can get it, I'll let you know ...

I've been trying everything I can think of also - from hidden controls that hold the last value to all the event handlers. Right now we're just going to live with it, but hopefully there is a better way. It only happens if you select the "next" item in the list, the one that's already selected. If you select the one after, that triggers the "onchange" and it works fine.

Thanks for your help!

Hi. I asked around and no one had any bright ideas. However, I did come up with something is a huge hack and that relies on leveraging the underlying technology of how controls do autopostback. Let me say again that this is quite a hack and would never be formally supported or guaranteed to work after upgrades.

So that said, it seems that you can try doing the following. In the client script for doing all the auto-select magic, find the idle() function and add the following line:

function idle(){


   // This function is called if the timeout expires. If this is the third (by default) time that the


   // idle function has been called, it stops the timer and clears the keyboard buffer





   timeoutCtr += 1


   if(timeoutCtr > timeoutCtrLimit){


      resetToFind();


      timeoutCtr = 0;


      window.clearInterval(timeoutID);


   }


   __doPostBack(oControl.id, "");


}

Not to belabor something you already know, but what this does is hard-code a call to the javascript function that ASP.NET generates to support autopostback. What's happening here is that when the idle timeout expires, the script not only sets the selection in the listbox (and, as we know, not firing onchange), but then posting as if onchange had fired.

(The reason I say that this wouldn't be a supported technique is that the team has not, as far as I know, documented this _doPostBack() function, hence probably would not feel obligated to support someone hijacking it as I'm showing here.)

This will only work if AutoPostBack is set to true for the control, otherwise there is no __doPostBack function rendered into the page.

You might want to play around a little with the idle timeout time and such -- it can be a little quick on the draw if you spend too much time reading the items after typing characters in.

Let me know if this works. And remember that this is not a supported solution ... :-)

It works great! I'll remember to watch out for it when we do next upgrade, but at least for the time being, it does the job.

Thanks again!

 

 

Try playing around with the code for COMBOBOX in HTML :

Editable DropDown Listbox with any one select option as Editable (like a textbox ) and the rest as readonly. It is a typeable combobox.

http://chakrabarty.com/pp_editable_dropdown.html

http://chakrabarty.com/combobox.html

Try playing around with the code for COMBOBOX in HTML :

 Editable DropDown Listbox with any one select option as Editable (like a textbox ) and the rest as readonly.

http://chakrabarty.com/pp_editable_dropdown.html

http://chakrabarty.com/combobox.html