[SWINGX-1453] JXDatePicker always consumes ENTER and ESC Created: 08/Jun/11  Updated: 15/Jun/11

Status: Open
Project: swingx
Component/s: Calendar
Affects Version/s: 1.6.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mwrekers Assignee: kleopatra
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

WinXP, probably all

Tags: ENTER, ESC, JXDatePicker, Keys


The JXDatePicker always consumes ENTER and ESC. This blocks the DefaultButton logic or the RootPane action (ESC) for closing a Dialog. For example JFormattedTextfield consumes ENTER and ESC only after starting editing.

JXDatePicker should only consume these keys after starting editing like JFormattedTextfield.

Comment by kleopatra [ 15/Jun/11 ]

arguable - it's behaving like a plain text field

for comparison with a core components, see the wiki and related debates (don't know if the links are still working, java.net migration hurt a lot), f.i.:


[LWUIT-429] Listen to soft keys on dialog/form Created: 13/Apr/11  Updated: 27/Apr/11  Resolved: 17/Apr/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tempusername Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Form, LWUIT, keys, soft



it is impossible to use the addKeyListener to detect soft key presses on dialogs/forms
since the keyReleased method in form calls the menubar if they detect soft key codes and does a return (even if there are no commands on the menubar.
In general i think the keyPressed/KeyReleased etc methods should return a boolean to know if the event was consumed or not thus allowing to continue propagate or not onwards.
We have our own UI lib that we build and we also did at first the mistake of not using a boolean on the return value, however this change might be too big atm for lwuit so perhaps the call the keylisteners at the start of the function or perhaps not doing a return.
i would also like to explain the underline cause to which we want to listen to soft keys.
we use dialogs to show the user ok/cancel questions etc and when the ok/cancel are used as soft keys they look a bit ugly and not connected to the actual dialog itself and its also not so friendly to touch devices. we saw there is a theme constant that allow the commands to be shown as buttons on the dialog but they dont respond to their relative soft keys to allow for both touch and non-touch devices to use it in intuitive manner so we tried adding our own buttons and using the keylistener to connect the soft keys to the buttons.

(sorry for the looooooooooooooong explanation)

Comment by vprise [ 17/Apr/11 ]

I'm marking this as fixed since I changed the behavior of commandsAsButtons to check the softbuttons internally and perform the command when a physical softbutton is pressed.

We have event.consume() the approach of returning false from a method is only practical for simpler API's that don't rely on the observer pattern. Even in this case its a problem since people need to be familiar with the call chain of event dispatch.

We don't expose softbuttons since we don't want people to "hack" them, they are a problematic none-portable concept. If you really want to get access to them you should replace the menu bar (which we now allow).

Comment by tempusername [ 27/Apr/11 ]


Was this change committed? i updated my src two days ago and i dont think its working.

Comment by vprise [ 27/Apr/11 ]

Yes: Dialog.java lines 919-935

Generated at Sun Dec 04 16:16:20 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.