Review request for 7142565 - [macosx] Many special keys processed twice in text fields (original) (raw)

Anthony Petrov anthony.petrov at oracle.com
Wed Feb 8 07:10:08 PST 2012

Looks perfect. Thank you!

-- best regards, Anthony

On 2/8/2012 8:07 PM, Anton V. Tarasov wrote:

On 2/8/12 1:35 PM, Anthony Petrov wrote:

Hi Anton,

The fix looks fine. Unless there are consistency considerations, you could move the declaration of the static variable into the method's body to localize the logic around this not-retained object pointer (and avoid adding any comments about that, too.) I'll leave this up to you and other reviewers. I put it to the top anticipating comments like you got for your fix (which I looked at). But ok, let's narrow the scope. http://cr.openjdk.java.net/~ant/7142565/webrev.1/ Thanks, Anton. -- best regards, Anthony On 2/8/2012 1:49 PM, Anton V. Tarasov wrote: Hello,

Please review a fix for 7142565. webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key events.) Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, another simple workaround is suggested. It's to store a pointer to the latest processed key event in AWTView and compare the current event to the previous one. In case the event objects are the same, ignore the second (current) one. Thanks, Anton.

More information about the macosx-port-dev mailing list