I'm working with the 8.1 version of the UltraComboEditor and I'm seeing something of an oddity and just wanted to get some feedback on it. I have a UltraComboEditor dropped onto a form, it is databound to a collection of objects, the DisplayValue and ListItemValue are both set to the same property of the object, the style is DropDownList and AutoComplete is set to true. The thing I see is that when AutoComplete is set to true and the user types letters while focus is on the control it sometimes will jump appropriately to the right element in the list and sometimes it won't.For example say the list contains:YesNoUnknownThe user goes in and presses the 'N' key, the control will jump have the index jump down to the No item and select it, however if you press say 'D' and then 'N' it sometimes doesn't do anything. It seems to happen the further down the alphabet you go. It is a bit sporatic but still noticable. When I set AutoComplete to false everything works as expected. I'm mostly just curious if this is the fix since I haven't really found anything in the docs or the forums that would explain this.
Thanks.
If I understand what you've described correctly, then I believe this is expected.
What's happening is that WinComboEditor is trying to process input that is "quickly entered" as a single input. In other words, if you press "D" and then "N", it looks for an entry that starts with "DN' and (of course) doesn't find it. You can test this more easily if you have a number of entries that all start with the same letter:
AardvarkAberforthAbleAppleAxisPear
In this list, if you hit "AP" quickly, it should jump to "Apple". If you hit "A," pause, then hit "P," you'll start at "Aardvark" and end up at "Pear".
This behavior is keyed to the AutoComplete property, and the above explains what happens when the control's drop-down style is DropDownList. If you turn AutoComplete off, then each key press is treated as an independent input.
The other drop-down styles instead match the text as input-so-far and fills in the rest of the input area with the first match it finds. DropDownList is different since it technically doesn't allow "direct" input into its input area.
Yeah that makes sense.
Out of curiosity what is the delay between hitting 'A' and 'P' and it going to Apple instead of Pear? To me it seems like a second and a half to two seconds, basically such that if someone is doing the hunt and peck method of typing they'd still get Apple.
Hi,
Yes, I agree. This is not the first time such a feature has been requested. I forgot to mention it, but I passed along this suggestion to the product manager as a potential enhancement for a future release. :)
Thanks Mike.I did something like that.
It would however be nice if Infragistics support that in the future. I have such behavior elsewhere.
There's no built-in way to do this. But you could trap the KeyDown or maybe KeyPress event of the control and mark e.Handled true if the new key the user typed won't match an item on the list.
Hi, my problem is that when I type "A" and then "B", I am shown,
AberforthAble
But then it allows me to type "Z", which obviously is not a valid entry. It then remains ABZ and prevents us from tabbing away until that is corrected (without raising validation) and if that field is not mandatory, it let's us tab away and ofcourse we need to handle that wrong value while saving data.
Is there a way to restrict typing only to those values that are in the list. For example, the key entry "Z" will not be allowed.
Is this possible?
bahern said:Out of curiosity what is the delay between hitting 'A' and 'P' and it going to Apple instead of Pear? To me it seems like a second and a half to two seconds, basically such that if someone is doing the hunt and peck method of typing they'd still get Apple.