jQWidgets Forums
jQuery UI Widgets › Forums › Lists › ComboBox › Workaround for autoItemsHeight with autoComplete
This topic contains 1 reply, has 2 voices, and was last updated by Peter Stoev 8 years, 9 months ago.
-
Author
-
I came across the same problem described in this thread:
Namely, you can’t use the autoComplete feature with the autoItemsHeight property. If you try to, your search string gets wiped out after each character you type.
Peter says the problem will be fixed in a future release, but if anyone else comes across this same issue, here’s a workaround for now. That thread is closed (due to the OP being rude), so I’m posting this in a new thread.
You can view an example of the solution here.
I’ll explain the important bits.
I’m not using the autoComplete option at all. Instead, I use the remoteAutoComplete option in conjunction with the search function.
The autoItemsHeight is set, and you’ll notice the source items have long labels that will need to wrap around to more than one line.
I also have a static source, for simplicity. You can also modify your search function to actually fetch a remote source if desired.
The search function filters the original source array. In the example, it’s equivalent to setting searchMode to ‘containsignorecase’, but you can search however you like. It then stores the search string away. The core of the original bug seems to be that for some reason, when autoItemsHeight is enabled, the search string is removed when updating the source. So with the search string safely tucked away, we can update the source freely and just reapply the search string when we’re done. If you have a particularly large filtered set or a complicated renderer function, this can cause some wonky behavior where if you keep typing while the source is being updated, the additional characters can be wiped out. So in the case of a large filtered result set, I’d suggest possibly limiting the size somewhat to avoid this.
I have the minLength option set to 0 so filtering will be done on any length input. The remoteAutoCompleteDelay is set to 0 for instantaneous filtering. If you’re using an actual remote source, leave this at something higher (like the default) to prevent overloading the web service you’re getting the source from.
With just these options in place, we’re almost done. You can filter just like you’d expect, and your search string stays intact. The only thing missing is that if you try to open the dropdown list on page load before searching for anything, no items show up. I haven’t set the source property because even if I do, nothing changes. So after initializing the widget, I just make one call to the search function with an empty string. This populates the dropdown with the full source set.
One other quirky behavior I noticed was that while using backspace to remove one character at a time properly reverts the list to its unfiltered state after removing the entire search string, if you ctrl+a then delete, the list often remains in its filtered state as though the search string hadn’t changed. I’ve got no idea why this is or if there are other quirks like this I haven’t found yet. But a hack to solve this is to add a listener on the ‘input’ event, check if the input is empty, and if so, trigger a search with an empty string to restore the unfiltered list. For some reason when doing this, if trying to remove the last character of the search string with backspace, it won’t be deleted. So just manually clear out the value.
And that’s it! I hope it helps someone who’s looking to use the autoComplete behavior along with the autoItemsHeight property.
(Oh, also, the ‘searchString’ method isn’t documented anywhere on the API reference page for the combo box widget. It should probably be added in. It’s crucial to this solution, but I just stumbled across it being used in one of the jsfiddle demos.)
Thanks for sharing this.
-
AuthorPosts
You must be logged in to reply to this topic.