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

[Mike Swingler]

The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance.

The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it).

Just a suggestion,
Mike Swingler
Apple Inc.

On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote:

> On 2/8/12 1:41 PM, Leonid Romanov wrote:
>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused.
> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent).
> 
> Thanks,
> Anton.
> 
>> 
>> 
>> On 08.02.2012, at 13:49, 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.
>>> 
>>> 
>