Question

I’d like to add a research functionality to a software I’m developing. The idea is to adding some kind of “indexed” research, so when the user types in a text-box another, gui-component show the filtered results. Ex:

User types: a
aaa
aba
aab

user types: aa
aa
aab

and so on.
Sure this thing has a name (as it is used almost everywhere), but I don’t know it and so until now I couldn’t find anything useful over the web. I don’t need the exact code, just a link to some resources (tutorial etc). Ty.

EDIT: I’m not looking for an autocomplete functionality: If I type in the textbox I’d like to see all the filtered result in a (for example) listbox near the textbox.

Answer 1

What you are trying to do is known as autocomplete (or it’s a variation of that, you are simply filtering a list on-the-fly), and is a very common feature.

It requires that you be able to look up against your data quickly, as you have to be able to update the list as the input is formed. Of course, input can come in the form of keystrokes, and some people are very fast typists.

If your list is contained in-memory and is rather small, then your best bet would probably to filter over the list for search criteria (I’ll refer to what is typed in the box as this).

If your list is not contained in memory, then you’ll need to index your data somehow. Generally, databases are NOT good for this sort of thing. Some have text-indexing (SQL Server does) and if that suits your needs, you query against that.

If you aren’t using a database, then you might want to consider using Lucene.NET to index your content. If your content is small enough, I’d recommend using the RAMDirectory, otherwise, the standard FSDirectory (file-based) will do fine.

With Lucene, you’ll want to use the Contrib.Shingles package (it might be included in the latest build, I’m not sure); this is an n-gram filter which tokenizes items by characters, so basically, you could search on the first few characters (the search criteria) and get results.

Regardless of the approach you take, you need to take into account the speed of the inputs that come in. If you perform lookups every time a key is pressed, you’ll have a good deal of requests that never will be applied.

Generally, you might want to start searching after the search criteria extends beyond two characters. Additionally, keep track of the number of requests that were made; if you have a request that is coming back and new input has been submitted, cancel the old request and submit the new request, the values from the old request won’t be used.

When it comes to the UI component, it’s better that you let another component vendor handle this; WinForms has an autocomplete mechanism for the TextBox, Silverlight has an autocomplete in the Silverlight Toolkit, jQuery has an autocomplete mechanism for web pages. Use one of those and shuffle your data to your control using the guidelines above.