Community
Participate
Working Groups
The intention of AutoCompleteField was to allow users to implement browser address-bar style type-ahead. Andrew Hoo tried to do this and found it lacking. Would be nice to address these things. Here is what he said: ----------------- Also, I noticed something that makes Address bars different, is that hitting the down/up arrow fills in the contents of the text-box. I didn't see a way to retrieve the currently selected item while the popup was opened. The current listeners on the adapters return when the popup opens/closes or a choice has been selected. I could almost get at the proper propsoal via: contentProposal.getContentProposalProvider().getProposals(currenttext, cursorpos) but that returns an array which I don't have the index to get the currently selected item. However, even assuming that I could get the selected item from the list and that I replaced the contents of the textbox with it, I would not want that to further filter my selection to only be that one when that text is modified. (I'm under the assumtion that filtering happens whenever the contents of the textbox changes). Looking at IE and Firefox and Opera, if a traversal key is pressed to change the selection of the predictive completion, then the contexts of the textbox is changed, but the filtered proposals are not. Only when the textbox is directly edited again by typing does the proposals refilter the list. ...I do like listeners and would have found a "selection changed" listener useful to make it even more address like as described above with necessary adjustment to selection by traversal and when/how to do filter.
marking 3.4. I really don't know that I'll have time to look at this, but it's a shame that Andrew had to implement his own autocomplete control....
note to self: if something like this is contributed (or implemented by me), it would be long overdue to also write up some structured, manual, cross-platform regression tests. I'm working on some regressions right now that indicate this is so. The best way to get a sample of this would simply be to look at the CVS history for ContentProposalAdapter and visit the various bugs. Many of them are regressions or corrections on top of a previous fix.
another note to self: the manual test case gathering described above is now done and avaiable in org.eclipse.ui.tests/Manual Component Tests/FieldAssist.txt
From bug #219777: >JFace auto completion works differently than web address auto completion >in the Firefox: After the popup dialog is opened, there is not selected any >proposal in the popup. User can hit: >1.Enter key - the current text in the address field is accepted and used. >2.Up/Down key - user travers via proposals in the popup and selected proposal >is copied into the address field and displayed there.
renaming so it's clearer what this bug is about
*** Bug 219777 has been marked as a duplicate of this bug. ***
removing 3.4 milestone. It's a good idea, there is just no allocated time to work on this for 3.4.
as per 2009 triage guidelines
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
