Review request for 7142565 - [macosx] Many special keys processed twice in text fields
anthony.petrov at oracle.com
Wed Feb 8 02:35:03 PST 2012
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.
On 2/8/2012 1:49 PM, Anton V. Tarasov wrote:
> 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
> 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.
More information about the macosx-port-dev