Not a JComboBox Bug
Here is a little Java program that creates a JComboBox with three identical “Green” items:
public class ComboDemo extends JFrame {
public static void main(String... args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new ComboDemo().setVisible(true);
}
});
}
public ComboDemo() {
super("Duplicates are Dumb");
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JComboBox combo = new JComboBox(new String[] {
"Red", "Green", "Blue", "Green", "Yellow", "Green"
});
add(new JLabel("Choose your favorite color:"), BorderLayout.NORTH);
add(combo, BorderLayout.SOUTH);
pack();
}
}
As you can see, the user really has no way to know which “Green” is the correct selection:
Some people want to display multiple identical items in combo boxes. I’ve had customers ask me for this feature — and I refused. If memory serves correctly, they were having keyboard navigation problems because focus would get stuck on the first of the duplicate items. Their database contained duplicate descriptions, and they wanted me to fix the alleged focus “bug” in the combo box rather than eliminate the duplicate descriptions in the database. (eventually, reason prevailed and we made the descriptions unique).
This has even been reported as a bug, and the ensuing comments are interesting to read. For example:
Good God sun!!! Just because you dont’ see why people would use the same string more than once in a JComboBox, it doesn’t mean that it isn’t need people like us!! Fix it please!!!
Yikes…imagine a GUI with these choices:
a) Yes
b) Yes
c) No
Um…
Apple’s Swing implementation has an interesting approach. When you click on one of the identical items, they are all selected:
This seems like a reasonable way for JComboBox to behave when given unreasonable data.
I think the key/value approach of html comboboxes is better, because they give you the choice to have both – duplicates allowed or not.
Sadly, I’ve had duplicate strings before, and used the index to differentiate (in VB6, I imagine, but maybe HTML).
For one example, imagine a hierarchy of items where there are sub-elements with the same title:
Sandwich
Turkey
Fish
Platter
Turkey
Fish
Sure there are better controls for this, but sometimes due to other design restraints this makes some sense. I can’t think of an example, but I’ve had cases where all items (parents and children) can be selected, so in the example above you might choose “Sandwich” or “Turkey” (under sandwich).
Yes, there are other ways to do this (and I would try my best to find a better way), but this is a semi-reasonable use for same values in the list.
Formatting was lost above – imagine indentation for the Turkey/Fish entries.
I also don’t have any problem with blocking the duplicates as it might force people to go for the better options.
Even though duplicate values are not good, it requires only a small change to allow JComboBoxes to use Maps; show the description, use the key.
Just extend JCombobox, have a constructor that takes a map and from that extract the keyset as the actual values for the combobox. Then define a renderer that shows the value from the map.
public JComboBox(final Map items)
{
super(new Vector( items.keySet() ));
// set the renderer
setRenderer(new ListCellRenderer()
{
public Component getListCellRendererComponent(JList list, Object value, int index, boolean isSelected, boolean cellHasFocus)
{
// find the key for this value
if (!items.containsKey(value)) throw new IllegalArgumentException(”The map does not contain key: ” + value);
iJLabel.setText( items.get(value).toString() );
return iJLabel;
}
JLabel iJLabel = new JLabel(”");
});
}
I’ve had the same request from clients regarding websites. In particular, one client had an application that included a (large) filterable employee list, but it only showed the user the employees’ names. Oops.
BTW, using indentation to denote option categories in a combo box has more problems than just this one. What happens if I select a category like “platter”, instead of an option?
At my day job we tend to have combo box lists with ‘public names’ that are pretty and ‘private names’ that are keys, or uuids, row numbers, or some other transformation, so this situation happens on occasion. (we don’t actually use public name and private name as our lingo, that’s just the lingo I got from my first job where I was working on Data Warehouse software).
What we have done to fix is is we don’t populate the ComboBox model with strings, but with a class that holds the public and private name with equals and hashCode running entirely off of the private name. We then slap a renderer on the combo box that will render the public name, so the ComboBox runs off of a discreet class without many conflicts.
Lucky for us our customers are a bit more reasonable, when presented with a public name collision we’ve always been able to get them to make the public names unique. Probably because they already have an appreciation of the problem when the split db keys away from user presentable data.
You should have read one other comment on that linked bug; while duplicates may and do confuse users, they may be invaluable for debugging. If the function is supposed to get selected index, it’s supposed to do just that, not pretend that several entries are the same because they have the same caption. A single GUI element is not a single database entry — it may not even be related to a database.
Overall, from user usability standpoint, I agree with your post. However the bug is still in the combobox implementation: it should avoid _adding_ duplicates into the list instead of just behaving in a dumb way. Even Apple’s solution is not good.
@ivucica the getSelectedIndex() method does not “pretend that several entries are the same because they have the same caption”, despite what the person said on the bug database.
The displayed value is determined by a renderer. Thus, your renderer might display duplicates, but it’s up to you to ensure each item in your data model is unique. Typically this is done via a unique identifier from a database table.
The getSelectedIndex() method does not operate based on the renderer. The JavaDoc comment is very clear: “Returns the first item in the list that matches the given item.”. And the implementation loops through the data model, and calls .equals() on each object in the model.
If a programmer puts two objects into a data model where both are .equals() to each other, that’s really not a combo box bug.
Like Danno Ferrin wrote, I too work on an application that has a “public name” and a “private name” that is a unique key for items in a combo box. Unfortunately, the original programmer who implemented our subclass of JComboBox populated it with Strings so we had the unfortunate incident of where a user would select the second instance of a duplicate entry and have it flip to the first selection after.
Since fixing this bug would require that I rewrite a whole bunch of code from scratch, I instead opted to leave it alone and instead put in a validation for when users try to create duplicate entries in the first place.