Unexpected search autofill behavior

[Robert Leach]

Delete key unexpected behavior in search select list. I understand what's going on here, though it took me a minute - it's auto-filling based on the currently highlighted item at the top of the drop-down list, but after I typed "GENE105", I decided I wanted "GENE10", but hitting the delete key to remove the 5 did not allow me to select GENE10 (without using the mouse). Instead, it stayed on GENE105.

The user can still ultimately do what they want to do using the mouse, but they may just type what they want and hit return without realizing they're not getting what they typed.

This behavior is visible in my debugging session screen recording at time index 10:34-10:54. You can download the 500MB file if you need to view it:

http://gen-rlimac.princeton.edu/~rleach/TREEVIEWBUGS/multiple_bugs/multiple_bugs.mov

Rob

[Robert Leach]

Changed to a bug since the user may not be able to figure out how to get what they want.

[Robert Leach]

I've nearly got this one wrapped up. It's currently working, but I need to account for modifier keys and the escape key - basically anything that doesn't add a character to the search term boxes.

I may publish this fix in a java forum or something - because it works much more intuitively than the default implementation of autocomplete.

[Robert Leach]

While what I've implemented works well when you're just typing, moving the cursor or changing the highlight with either the arrow keys or the mouse leads to incorrect/unexpected behavior and it seems that trying to account for these use cases is complex. I think it will take awhile before this branch is ready, so I will treat it as a lower priority item. I need to get some stuff done on another project before the break.

[Robert Leach]

Finally got around to finishing this. Been working on another project. I also ended up redoing what I'd tried the first time around and the solution is more complete, i.e. it works even if you manually move the cursor or change the selected text. It didn't turn out being any simpler code than the first go-round. I think that the crux here is that we're using the autocomplete core code in a way that it wasn't designed (by allowing wildcard searches). The code was originally intended to select only 1 static result. When you allow no static result selected (because of wildcard characters), unexpected things happen because predicting when the parent class is going to decide to follow through with the text editing and update the selected text and selected drop-down index and when it's not was pretty tricky. I believe I have accounted now for every quirk. The only downside I see is that the cursor/selection visually hops around sometimes. It ultimately ends up where one would intuitively expect, but if you're watching as you type, it can be a little disorienting. once thing that wasn't quite as intuitive as I expected was when I decide to treat the selected text as autocompleted text versus manually selected text - and what to do when the arrow keys are pressed. Hopefully it's acceptable, because it would be a chore to change. I left a bunch of debug log prints that you can turn on/off with a debug variable in the class where the methods are in case anyone decides to change anything in the future.