Review request for 7142565 - [macosx] Many special keys processed twice in text fields
Anton V. Tarasov
anton.tarasov at oracle.com
Wed Feb 8 08:07:19 PST 2012
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