Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane

[Anton V. Tarasov]

Hi Anthony,

option+char produces a special unicode symbol and actually may not generate KEY_TYPED at all (it 
won't with the fix for 7144063). Instead, it synthesizes InputMethodEvent.

So, your suggestion is applicable to KEY_PRESSED/KEY_RELEASED for which a valid keyChar is not 
mandatory (but perhaps, we may provide it if we get it).

Thanks,
Anton.

On 13.03.2012 19:01, Anthony Petrov wrote:
> Hi Alexander,
>
> How about doing something more generic, like the following:
>
> chars = [ev chars];
> if (chars is empty) {
>    chars = [ev charsIgnoreMods];
> }
>
> ? What might go wrong with such approach? In this case we'll also see chars=='e' for Option+e. 
> Would that be a bug, or would it be actually something that we'd like to see?
>
> -- 
> best regards,
> Anthony
>
> On 3/13/2012 5:13 PM, Alexander Scherbatiy wrote:
>> Please review a fix for 7151821.
>>
>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/
>>
>>
>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to 
>> [event characters] during the MACOSX_PORT-568 issue fixing:
>> http://java.net/jira/browse/MACOSX_PORT-568
>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e
>>
>> The characters string is null during Ctrl+Alt+Char mnemonic pressing.
>>
>> According to the NSEvent charactersIgnoringModifiers doc:
>> This method returns the non-modifier key character pressed for dead keys, such as Option-e.
>> For example, Option-e (no shift key) returns an “e" for this method, whereas the characters 
>> method returns an empty string.
>>
>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic 
>> key combination is pressed.
>>
>> Thanks,
>> Alexandr.
>>