Community
Participate
Working Groups
Build Identifier: swt-3.8M3-cocoa-macosx-x86_64 Perhaps this is a matter of opinion and esthetics. It seems odd that when, say, command alone is pressed a keyDown event is generated, but with the stateMask modifier for command as zero. However, when control is down and then command is pressed, stateMask shows that control is down (and not command). In both these cases, the true and actual state of the keyboard modifiers is that command is down. Yet Widget.setInputState goes to extraordinary effort to unset the command bit from event.stateMask. So I make my argument from two perspectives. 1) Consistency, semantics, and esthetics; and 2) in the actual practice of writing my code to use stateMask in a real-world application, I have to sacrifice code and clarity to undo the clearing of that modifier key bit that is done in setInputState. Thanks for listening. Reproducible: Always Steps to Reproduce: 1. Install a keyDown event filter. 2. Press the command modifier key. 3. The generated event's stateMask is zero.
(In reply to comment #0) A followup... I found an explanation for the intention behind this behavior in 3rd party docs separate from the eclipse website. It is that stateMask intends to show the modifiers held before a new modifier key is pressed and before it is released. IOW, these are the modifiers to the modifier. Now I'm not sure how to critique this design diplomatically and humorously: at least there is a consistency. But I am willing to bet no software exists in the entire past-present-future space-time of our Universe that finds this design helpful. In the case of my software, I need to know the modifier state in real-time, NOT at a user event. This means saving their state using a keyDown listener and a keyUp listener, both correcting for the removal and addition of the current modifier. Besides dealing with the "modifiers on modifier" design issue, a Display.getCurrentModifiers() method would be practically useful. Thanks.
By design, key events are sent to the application *before* they are handled by the system. This is important to allow the application to stop a key event from being handled by the system. So, during the key down event for command key the command bit is not in the mask because the system has not yet seen it. Likewise, during the key up the command is still set in the mask. This design is quite common, see win32, X, etc (in mac it is different, so we had change for consistency sake). Note that it is fairly easy for you calculate the "future mask", that said, if you want to run some action when control is down and command is pressed why not looking for (stateMask&CONTORL) != 0 && keyCode == COMMAND ?
