Skip to main content

AutoCompleteDecorator and editable JComboBox

10 replies [Last post]
aliasvector
Offline
Joined: 2009-03-23

Hello All!
I have editable JComboBox which contains items: ..., "element", "Element", ...
I don't know how to do that a be able to select or type in "Element". I always get "element"?
This is my code:
org.jdesktop.swingx.autocomplete.AutoCompleteDecorator.decorate(jMyComboBox);

Here filling of my combobox:
DefaultComboBoxModel dcbm =(DefaultComboBoxModel)jMyComboBox.getModel();

dcbm.removeAllElements();
dcbm.addElement("item 1");
dcbm.addElement("item 2");
...
dcbm.addElement("element");
dcbm.addElement("Element");
...

So. Could anyone help me with it? Thank you in advance!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08

The decorator ignores case. The original decorator differentiated case, but also required users to type case exactly and was dropped in favor of the current approach. It seems like we need a way to specify sensitivity.

Karl

aliasvector
Offline
Joined: 2009-03-23

But is it difficult to analyse if there is in list an exact match? If there is not, then look for item ignoring case...

kschaefe
Offline
Joined: 2006-06-08

Huh?

aliasvector
Offline
Joined: 2009-03-23

I tryied to extend AbstractCompleteDocument with this functionality, but alas I have exceptions. I just think that someone has done this already that's why I've written this topic.

For exmaple:

First wee look for exact match:

for(int i=0; i ...
if(itemList.get(i).toString().equals(pattern)) {
setSelectedItem(itemList.get(i));
return;
}
...
}
//If we didn't find exact match
for(int i=0; i ...
if(itemList.get(i).toString().equalsIgnoreCase(pattern)) {
setSelectedItem(itemList.get(i));
return;
}
...
}

aliasvector
Offline
Joined: 2009-03-23

for(int i=0; i ...
if(itemList.get(i).toString().equals(pattern)) {
setSelectedItem(itemList.get(i));
return;
}
...
}

if we didn't find

for(int i=0; i ...
if(itemList.get(i).toString().equalsIgnoreCase(pattern)) {
setSelectedItem(itemList.get(i));
return;
}
...
}

kschaefe
Offline
Joined: 2006-06-08

It's a bit more complex than that. Consider the following list of elements:
1. El
2. ele
3. element
4. Element

If you type "E" and "l", you'd match 1.
If you type "E", "l", and "e" you'd match 2.

What would you match if you typed "E", "l", "e", "m", "e", "n", "t"?

Surprisingly, or not, it would be 3. The document text for the "E" is going to be converted to "e", when "ele" is matched.

I suggest filing a bug for the issue, but I will need to think a bit harder about a solution. Ideas and patches welcomed.

Karl

aliasvector
Offline
Joined: 2009-03-23

> 1. El
> 2. ele
> 3. element
> 4. Element
>
> If you type "E" and "l", you'd match 1.
> If you type "E", "l", and "e" you'd match 2.

Why???
The first "for" cycle will find exact match with the forth element!!!

> What would you match if you typed "E", "l", "e", "m",
> "e", "n", "t"?

The forth element "Element"

Firtly the first cycle "for" run along all list items looking for exact match(clause equals)! If there is not the one, then start the second "for" cycle (because return clause was not reached in first cycle).
And in the second cycle the clause "equalsIgnoreCase" works!

kschaefe
Offline
Joined: 2006-06-08

> Why???
> The first "for" cycle will find exact match with the
> forth element!!!

Because there is an implicit conversion from "E" to "e" occuring when you match 2 and all future typing will use the converted "e" for matching.

Karl

aliasvector
Offline
Joined: 2009-03-23

Conversion??? When?
1. Element
2. element
3. Item
4. Text
5. elisa

You type 'E' and in the first cycle you move to the first element by "equals". And combobox text is become E{lement} ( {selected text} ).
No conversion in this case!
Then you type 'l'. And NOT selected text is "El". You again move to the first element in the first cycle. Your text now is El{ement}.
But if you then type 'i' your NOT selected text is Eli and in the first cycle you do not find exact match by "equals". The second cycle finds the fifth element "elisa" by "equalsIgnoreCase"! And here we get text eli{sa} in our combo box. Here conversion will be done.. Only here. And this is right.

kschaefe
Offline
Joined: 2006-06-08

Again you're missing the point that in the previous example (my example), there was an "ele" element in the list. When the combo box sets that value as the value it looses the "E" that you type because it has a valid selection "ele". Typing another character will use the currently valid selection, since the selection is complete and not partial. A conversion will occur. In your example, there are no implicit capitalization conversions and nothing to worry about. We can't just patch for your example, we need to consider all cases. Just adding the preferential match on equals then equalsIgnoreCase is going to give inconsistant behavior.

I'm not saying that there's not a better way of doing it. And I'm not saying it's not a bug/rfe. What I am saying is that we need to consider complex cases that can occur before determining how to implement that behavior.

Please file free to file a bug in the tracker.

Karl