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.

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.

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.

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?

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 also don’t have any problem with blocking the duplicates as it might force people to go for the better options.

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.