<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