Issue Details (XML | Word | Printable)

Key: SWINGX-1532
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Karl Schaefer
Reporter: robin_stevens
Votes: 1
Watchers: 0

If you were logged in you would be able to see more operations.

Improve usability for the autocomplete combobox

Created: 30/Oct/12 06:22 PM   Updated: 02/Nov/12 10:43 AM
Component/s: Autocomplete
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive (3 kB) 30/Oct/12 06:22 PM - robin_stevens
2. Zip Archive (4 kB) 31/Oct/12 02:15 PM - bobndrew

Participants: bobndrew, Karl Schaefer, kleopatra and robin_stevens

 Description  « Hide

Also see

The use-case is having an editable auto-complete combobox where you want to trigger a long-running task when the user has finished changing the selection. You do not want to trigger the long-running task when

  • the user is still typing
  • the user is navigating with the keyboard arrows
  • the user is navigating with the mouse

You do want to trigger the long-running task when

  • the user selects an item with the mouse
  • the user types an item and confirms with ENTER
  • the user selects an item using keyboard arrow navigation and confirms with ENTER

I did not manage to fulfill all these requirements. Attached to this issue 3 classes which show 3 approaches, but none of them work completely. The ImprovedApproach comes closest, but still requires an ENTER after mouse selection.

The last issue usability issue is editing of an existing item to a slightly different one. This is present in all 3 of the samples attached to this issue. You override way too easily the auto-completed part, e.g. in the ImprovedApproach sample do

The actual example which was reported by one of our users was the editing of //SERVER1/Data/... to /server/data/..., so having an option to switch off case-insensitive auto-completion is not enough.

bobndrew added a comment - 31/Oct/12 01:56 PM - edited

Running the and the example showed the same behaviour... because the same class was instantiated
  public void run() {
    new NaiveApproach().show( "Button only" );

I fixed that and added a new class to the file which works as you described in your use-case. I used an ActionListener on Button1 clicks (like kleopatra suggested on stackoverflow).
  public void actionPerformed(ActionEvent e)
    if ((e.getModifiers() & InputEvent.BUTTON1_MASK) != 0)

A new problem is that the CombobBox in your example is editable; because of that 3 action events are fired (mentioned here in the forum) after mouse-clicking. One empty and two events with the new selection. If the ComboBox is not editable only one event is fired.
I debugged and read through the code. Maybe the selecting flag should be true when entering the remove(int offs, int len) method?

I have no ideas regarding your "usability issue", sorry.

(tested on Windows 7 64bit, Java 1.7.0_07-b10)

bobndrew added a comment - 31/Oct/12 02:15 PM

fixed and new example

Karl Schaefer added a comment - 31/Oct/12 03:52 PM

The forum example (for three events) is invalid because the combo box is being used as a cell editor. The correct listener to use is a CellEditorListener on the ComboBoxCellEditor and not an ActionListener on the decorated JComboBox.

Furthermore, I don't understand the point of this bug. If you want to ensure that the user is done selecting, you need to give the user a way to specify that, such as a button.

robin_stevens added a comment - 31/Oct/12 09:56 PM

@Karl Schaefer

I have a button, but it is very counter-intuitive that you have to click it after selecting an item from a combobox. Therefore I tried having all the possibilities: use the button, type + hit ENTER, mouse selection, keyboard navigation. But that is probably more a problem with a JCombobox then with the auto-completion.

However, there is still the 'editing an existing entry' usability issue as described above. I just logged this issue with the illustration on how I am using the auto-completed combo box, including all weird constructions trying to only trigger the connection when the user has finished editing. Might have been that I was using the component completely wrong ...

bobndrew added a comment - 01/Nov/12 09:50 AM

@Karl Schaefer

The point of this bug is the attempt to make an auto-complete-ComboBox behave like the adress-/search-ComboBox-Field in recent internet browsers.

If you type a URL or a search term in Firefox you get matching adresses in a popup. If you hit enter or click an item the website is loaded. In Firefox there's is an (optional) tiny arrow button, like you mentioned, to give the user the possibility to start the webpage loading. But it's only visible if you typed something new; it's replaced with the "add to favorites" button, after the pages is loaded.

In Opera and Safari there is no "Go to URL now!"-button anymore: just enter-keying and mouse-clicking.

kleopatra added a comment - 02/Nov/12 10:42 AM - edited

Actually, we already support the WorksAsDesired - in the ComboBoxCellEditor The implemenation is different from the one I suggested on SO but to a similar effect.

  • install a ComboBoxCellEditor around the decorated comboBox
  • for commit-semantic notification, add a CellEditorListener to the editor
final JComboBox withEditor = new JComboBox( new String[]{
        } );
    withEditor.setEditable( true );
    AutoCompleteDecorator.decorate( withEditor );
    ComboBoxCellEditor editor = new ComboBoxCellEditor(withEditor);
    CellEditorListener listener = new CellEditorListener() {
        public void editingStopped(ChangeEvent e) {
            connectToItem((String) withEditor.getSelectedItem(), outputArea);
        public void editingCanceled(ChangeEvent e) {
    contentPane.add(withEditor, BorderLayout.SOUTH);