Ian Roper ha scritto: > Greetings all, > > I am looking for a better way to locate and select an entry in a combo > or list box by pressing a series of keys. > > I have been able to do this with the following code but there must be a > better way. ? > > It would be nice to have this as a standard method for these sort of > controls. :) > > 'Pressing Esc clears the search string. > 'Label_Search displays the current search string. > > PUBLIC SUB Listbox_KeyPress() > DIM Count AS Integer > DIM Found AS Boolean > DIM SearchLen AS Integer > > Found = FALSE > > IF Key.Code = Key.Esc THEN > SearchString = "" > SearchLen = 0 > Label_Search.Text = "No Search" > ELSE > SearchString = SearchString & UCase(Key.Text) > SearchLen = Len(SearchString) > Label_Search.text = SearchString > ENDIF > > REPEAT > IF UCase(Left(Listbox[Count].Text, SearchLen)) = (SearchString) > THEN > Found = TRUE > END IF > INC Count > UNTIL Found OR (Count = (Listbox.Count - 1)) > > IF found THEN Listbox.index = Count - 1 > > END > > PUBLIC SUB Listbox_LostFocus() > > SearchString = "" > > END > It think this method is nice, and I think there is no other way to get the same result. Perhaps I only would add that, if the user presses cursor key movements, then the search string is cleared (what happens if the user presses key down a few times? I think an inconsistency shows up, because the search string shows something, and the combobox shows something else). If you experience some strange behaviour, try to use "STOP EVENT" somewhere before exiting the keypress handler.
I have done something similar some time ago, and I had a timer which, after a few seconds (500 ms?) of no typing, cleared automatically the search string - this saves the user to press Esc to clear the string, but it depends a lot on what kind of application you are writing. Then, Benoit said to me that this kind of comparison (if ucase(...) = ....) only works with ascii strings, so more specific string comparison functions should be used. It would be nice to have this search intrinsic in combobox, listbox, treeview and everywhere many strings are present, but it should be excludable, because there can be two problems. First, in some application it could be undesirable, or wanted a little different. For example, in some application, you can press several times the same key, say, "B", and get "Benoit", "Blengino", "Bozo" and so on. The second problem is when the listbox has thousands items inside it - it could get unresponsive, because the search code can take a few (or many) seconds. I don't like long listboxes/comboboxes and I try to manage them in some other way if I suspect they can grow too much, but this is my personal taste. These are just my opinions, many users think differently than me... Best regards, Doriano Blengino ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user