Pressing a key in combo fires onChange

Suite and Optimus Suite 5
#1

I’m using a combo with readonly true. When the user opens the list, then presses a letter key, the list scrolls to the first item that starts with that letter. This is good. But it also selects that item and fires the onChange event. This is undesirable as the user has not actually selected the item and the list remains open.

Is there any way to stop the onChange from firing when this happens or to determine within the onChange event if it has been triggered this way?

#2

onChange doesn’t occur in this case. Do you use the latest version ?

If the issue isn’t solved, please attached the demo where we can test the problem.

#3

I just tried with dhtmlx 2.6 and I see the same problem. The attached zip illustrates this.

You can also see another issue demonstrated in this code. If you open the option list, then move your mouse to the right and click on blank space in the browser, the option list closes, as expected. However, if you move your mouse down over the end of the list and click on blank space below the option list, the list does not close.

I’ve tested in both IE 8 and Firefox 3.6.
Combo Issues.zip (1.94 KB)

#4

I see the issue. In the readonly function, if auotosearch is not false, it adds this onkeyup handler:

			this.DOMelem.onkeyup=function(ev){ 
				ev=ev||window.event; 
				if (ev.keyCode!=9) ev.cancelBubble=true;
				if((ev.keyCode >= 48 && ev.keyCode <= 57)||(ev.keyCode >= 65 && ev.keyCode <= 90)){
					for(var i=0; i<that.optionsArr.length; i++){
						var text = that.optionsArr[i].text;
						if(text.toString().toUpperCase().indexOf(String.fromCharCode(ev.keyCode)) == 0){
								that.selectOption(i);
								break;
						}
					}
					ev.cancelBubble=true;
				}
			}

Note that it calls that.selectOption(i). If I change this to that.selectOption(i,false,false) it works as expected. I believe that the current behavior is not desirable. Even with autosearch on, it should move to the item that starts with the letter typed, but not fire the onChange. This is consistent with standard select behavior.

Also, I think it should ideally buffer keys and allow the user to click multiple keys. For example, if the user types “fi” quickly, it would move to the first item starting with “fi” rather than searching first for “f” and then for “i”. Again, this would be consistent with standard browser combo boxes.

#5

Hi,

yes you’re right regarding the readonly mode and onChange event. We’ll add the fix into the next combo version.
We’ll consider your idea about key buffer.
Thank you.

#6

Thanks, Alexandra. Just FYI, here’s how I implemented both the fix for onChange firing and key buffering:

dhtmlXCombo.prototype.readonly = function(mode,autosearch){
  this.DOMelem_input.readOnly=mode ? true : false;
  if(autosearch===false || mode===false){
	  this.DOMelem.onkeyup=function(ev){ }
  } 
  else {
	  var that = this;
	  this.DOMelem.onkeyup=function(ev){ 
		  ev=ev||window.event; 
		  window.clearTimeout(that._searchTimeout);
		  if (ev.keyCode!=9) ev.cancelBubble=true;
		  if((ev.keyCode >= 48 && ev.keyCode <= 57)||(ev.keyCode == 32 || (ev.keyCode >= 65 && ev.keyCode <= 90))){
		    if (!that._searchText)
		      that._searchText="";
  		    
			  that._searchText += String.fromCharCode(ev.keyCode);
			  for(var i=0; i<that.optionsArr.length; i++){
				  var text = that.optionsArr[i].text;
				  if(text.toString().toUpperCase().indexOf(that._searchText) == 0){
						  that.selectOption(i,false,false);
						  break;
				  }
			  }
			  that._searchTimeout=window.setTimeout(function() {that._searchText="";}, 750);
			  ev.cancelBubble=true;
		  }
	  }
  }
};