[Rant on]
Those damned f** XXEditors are dumb, useless and not doing their job
correctly - and we are on jdk1.3
[Rant off]
Now the reason for the above (this time examplified on ComboBoxes).
After running into a couple of problems with editable ComboBoxes I sat
down and checked API, bug database and sources. The general result is
that JComboBox and the default implementation of ComboBoxEditor (that's
BasicComboBoxEditor) are firing ActionEvents incorrectly in considerable
amount of cases in both directions - either too many or not enough.
The relevant situations are pressing ENTER or losing focus (either by
tabbing out or clicking into a different component), both with either
having changed the text in the editor or not having changed the text.
If the items are Strings then we get the following ActionEvents:
from: Enter Enter Tab Tab
/with /wout /with /wout
-----------------------------------------------
ComboEditor yes yes no no
ComboBox yes yes yes no
I consider everything in colum Enter/wout a bug, plus not firing from
ComboEditor if the text has been changed (there is some discussion about
similar issues in bugs #4145134, #4145135, rfe #4147484).
That becomes evident by studying the API for addActionListener for both:
ComboBoxEditor: event is generated "when the edited item changes"
ComboBox: event is generated "when user finishes making a selection"
As both are a bit vague I have to interpret what they mean (could be
wrong here not being a native english speaker):
As the present tense in the first would require to send an event
whenever a char is changed I assume it to mean "has changed", or in user
terms: whenever the user makes a gesture that the input is complete for
the time being (similar to cellEditorEvent.editingStopped()).
The second is even more unclear - in analogy to listSelectionEvents I
tend to interpret it to mean a "selection change". With this it should
fire in parallel with itemEvents.SELECTED.
With this in mind it is evident that pressing enter without having
changed the text should fire nothing - neither the edited item nor the
selection has changed.
The opposite situation is when comboBoxEditor does not fire an action on
focuslost - but selection is changed because of changes to the edited
item. It's definitely the ComboBoxEditor's responsibility to decide when
the edited item changes. If it decides not to regard the state on
focuslost as somehow final in terms of user gestures, then no other
object should interfere with this decision. In my opinion it should
decide to fire, though; otherwise data integrity might suffer.
As is the decision is smeared between JComboBox and BasicComboBoxUI
while ComboBoxEditor simply does nothing. JComboBoxes jumps in when it
receives a not filtered actionEvent from comboBoxEditor after enter
without any changes; BasicComboBoxUI (better: editorFocusListener)
checks on focusLost on the editorComponent. Both perform a similar task:
check if the current editorValue is the same as the combo's
selectedItem: if they are equal JComboBox prevents generation of
itemEvent; if different BasicComboBoxUI notifies JComboBox of a changed
item (very dirty by invoking it's actionPerformed() which is clearly
marked as being public as a side effect, should _never_ be invoked
directly - grrrrr).
And again (as with DefaultTableCellEditor) a less then optimal
implementation of the editor provoked the component/delegate
implementations to fiddle into tasks they should not be concerned with.
What makes the situation really annoying is, that it's very difficult to
implement it cleanly now. It's not enough to provide a ComboBoxEditor
that complies to the api, I had to subclass the component/delegate to
get rid of their interference...
Any comments?
Jeanette
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
