Review request for 7142565 - [macosx] Many special keys processed twice in text fields
swingler at apple.com
Wed Feb 8 07:35:02 PST 2012
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,
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).
>> On 08.02.2012, at 13:49, 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