<AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx] robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph key VK_ALT_GRAPH.

Semyon Sadetsky semyon.sadetsky at oracle.com
Thu May 26 07:35:12 UTC 2016


On 5/24/2016 2:09 PM, Manajit Halder wrote:

> Hi Semyon,
>
> It is not clear in the comment what was the problem, but it looks like 
> the problem was observed just by 
> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don’t see 
> any issues just by using the fix. It posts all the key events and all 
> the key events are tested in the test file modified along with the fix.
If you found the comment is not actual anymore, why did you preserve it?

--Semyon
>
> Apart from the unknown problem mentioned in the existing comment this 
> fix has following advantages:
>
>   * Key codes for modifier key are required to distinguish between Alt
>     and Alt-Gr key, which is not possible by using existing solution
>     as it doesn’t post key codes for modifier keys. And also
>     keys can’t be distinguished base on modifier value, which is same
>     for both keys (Alt and Alt-Gr).
>   * As mentioned in the existing
>     comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>   * Online search about keyboard simulation showed
>     that CGEventCreateKeyboardEvent/CGEventPost is used to simulate
>     key stores in most of the cases.
>   * Tested the key codes, didn’t observe any problem.
>
>
> Regarding number keys not working 
> with CGEventCreateKeyboardEvent/CGEventPost:
> Solved the problem by providing event source 
> to CGEventCreateKeyboardEvent. Code is modified.
>
> Please review the modified code:
> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/ 
> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.02/>
>
> Thanks,
> Manajit
>
>> On 20-May-2016, at 12:02 am, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manajit,
>>
>> Before your fix all key codes wa sent using
>>
>> AXUIElementCreateSystemWide();
>>
>> and CGEventCreateKeyboardEvent was commented or excluded from 
>> compilation:
>>
>> 274 #if 0
>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, keyCode, 
>> keyPressed);
>>  276     if (event != NULL) {
>>  277         CGEventPost(kCGSessionEventTap, event);
>>  278         CFRelease(event);
>>  279     }
>>  280 #endif
>>
>> I just wonder why it was done. Maybe that was some other issue fix. 
>> The comment above states:
>>
>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost would 
>> have been
>>  263      * a better solution, however, it gives me all kinds of 
>> trouble and I have
>>  264      * no idea how to solve them without inserting delays 
>> between simulated
>>  265      * events. So, I've ended up disabling it and opted for 
>> another approach
>>  266      * that uses Accessibility API instead.
>>
>> I don't understand what trouble is mentioned in the comment above. 
>> But in your fix you've put the CGEventCreateKeyboardEvent back, may 
>> it return this trouble back?
>>
>> Also as I understand Numpad number keys did not work as well. Could 
>> you add the corresponding test case since you provide a fix this 
>> extra issue?
>>
>> --Semyon
>>
>>
>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>> Hi Semyon,
>>>
>>> The fix is changed a bit because it was observed that the modifier 
>>> keys plus alphabet keys were not working together. In the modified 
>>> fix only Num keys are posted by AXUIElementPostKeyboardEvent and 
>>> remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The 
>>> fix is explained in the comment in file CRobot.m.
>>>
>>> Please review the new changes:
>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>_
>>> _
>>> _
>>>
>>> Answers to your questions:
>>>
>>> What is difference between AXUIElementPostKeyboardEvent and 
>>> CGEventCreateKeyboardEvent?
>>>
>>> Difference as per the documentation:
>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent 
>>> (which synthesizes a low-level keyboard event on the local machine), 
>>> but it allows you to specify the target application as opposed to 
>>> always sending the events to the active application. If the 
>>> system-wide accessibility object is passed in the application 
>>> parameter, the event is sent to the active application.
>>>
>>> Difference behaviour as per the implementation observed while 
>>> debugging the code:
>>> AXUIElementPostKeyboardEvent:
>>> AXUIElementPostKeyboardEvent posts 0 key code for all the modifier 
>>> keys with key codes 16, 17,18, 20, 157 and also for newly added 
>>> modifier key VK_ALT_GRAPH. But it posts correct key code for all the 
>>> remaining keys.
>>> While debugging it was that for modifier keys keyDown and keyUp 
>>> events are not generated, but flagsChanged event (flagsChanged: 
>>> (NSEvent *)event) is generated. But for all other keys keyDown 
>>> followed by keyUp events are generated.
>>>
>>> CGEventCreateKeyboardEvent:
>>> CGEventCreateKeyboardEvent posts correct key code for all the keys 
>>> except for numeric keys (numbers 0 to 9 on normal 
>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes for the 
>>> number keys 0 to 9. Instead of posting number key codes it posts 
>>> Numpad key codes for the corresponding number key. For example 
>>> Numpad0 key code is posted for number 0, Numpad1 key code is posted 
>>> for number 1 and simillarly for remaining num keys.
>>> Why the latter was commented? Does it mean that valid modifier keys 
>>> have not been sent by AWT robot?
>>>
>>> I didn’t get your question clearly. If you meant why in the current 
>>> implementation the later part (fix using CGPostKeyboardEvent) of fix 
>>> was commented.
>>> I am not very sure about it. As per the comment it is only clear 
>>> that CGPostKeyboardEvent/CGEventPost would have been a better 
>>> solution and I agree with that, perhaps reason could be related to 
>>> the difference in behaviour observed while debugging the code as 
>>> mentioned above.
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> Hi Manajit,
>>>>
>>>> Just a few questions to clarify on the fix.
>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>> CGEventCreateKeyboardEvent?
>>>
>>>> Why the latter was commented? Does it mean that valid modifier keys 
>>>> have not been sent by AWT robot?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK9.
>>>>>
>>>>> *Bug*:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>> _
>>>>> _
>>>>> *Webrev*:
>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>
>>>>>
>>>>> *Issue: *
>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key 
>>>>> event for Alt-Graph key VK_ALT_GRAPH.
>>>>>
>>>>> *Cause: *
>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it is 
>>>>> not mapped to any key on the OS X platform.
>>>>>
>>>>> *Fix: *
>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on 
>>>>> Mac OS X.
>>>>>
>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the 
>>>>> following reason:
>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the 
>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also for 
>>>>> newly added modifier key VK_ALT_GRAPH.
>>>>> But it posts correct key code for all the other keys. On the other 
>>>>> hand CGEventCreateKeyboardEvent posts correct key code for all the 
>>>>> modifier keys and
>>>>> hence it is used to post modifier key events and 
>>>>> AXUIElementPostKeyboardEvent is used to post all the remaining key 
>>>>> events.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160526/8610eac5/attachment-0001.html>


More information about the awt-dev mailing list