 |
Home | Changes | Index | Search | Go
Series on core Swing inconsistencies: center of interest here is JComboBox' action- and itemEvent firing and experimenting with alternatives.
Problems
JComboBox fires multiple actionEvents (with different commands) on a single (even programmatic) change. This indecent verbosity makes it hard to use. Further complication arises from the notion of a per-form default action (as implemented JRootPane's DefaultButton). Typically, per-component readiness is signalled by the same user gesture (ENTER) as the per-form readiness. This is a problem if the readiness gesture happens on a ready-aware-component inside of a ready-aware-form.
TODO: doesn't respect model completely
TODO: doesn't fire itemEvents on setModel
Spec draft
Intended behaviour for ActionEvent notification:
- fire ActionEvent only on "ready" user gestures
- do fire ActionEvent if "ready" gesture finalizes internal state changes
- fire a single Action event on "ready" user gestures
- ignore "ready" gesture if not consumed for internal finalization (or in other words: let it pass to default button)
Definition of not-finalized internal state and gestures to finalize
- after typing into the combo's editor
- press enter (popup visible or not)
- transfer focus somewhere else (popup visible or not)
- mouseReleased into popup's list (popup visible)
- after opening popup
- press enter
- mouseReleased into popups list (selection changed or not)
- after navigating by keyboard (arrow keys)
- press enter (popup visible or not)
- mouseReleased into popup's list (popup visible)
- TODO: after navigating by look-ahead keys
- TODO: autocomplete
Links
|