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

[Anton V. Tarasov]

Hi Mike,

On 08.02.2012 21:48, Mike Swingler wrote:
> Ok, as long as nobody is sending any messages to it, the retain/release dance doesn't need to be done. I'd suggest changing the name to sUnretainedLastKeyEvent, and changing the type to (id) so nobody is tempted to try to message it in the future.

I'm ok with it. Here is the latest version:

http://cr.openjdk.java.net/~ant/7142565/webrev.2/

Thanks for the review!

Anton.

>
> Thanks,
> Mike Swingler
> Apple Inc.
>
> On Feb 8, 2012, at 9:16 AM, Anthony Petrov wrote:
>
>> Hi Mike,
>>
>> We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM.
>>
>> Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body.
>>
>> [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/
>>
>> --
>> best regards,
>> Anthony
>>
>> On 2/8/2012 7:35 PM, Mike Swingler wrote:
>>> 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.
>>>>>>
>>>>>>