Hi,
Are you sure that keyPress/keyRelease should emulate UTF8 symbols?
Physical keyboard cannot produces so many keycodes with a single
press/release.
--Semyon
On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:
Hi All, Please review fix for the /_enhancement_/ wherein the robot
key press of non-ascii were interpreted as question marks.
Issue: The robot key press events was handling only the ascii inputs
and ignored the other Unicode inputs. Either it was throwing illegal
argument exception in windows or does nothing on the mac for those
Unicode inputs.
Solution and fix: The platform specific api’s was unable handle the
non-ascii inputs. I have modified the api’s to accept the non-ascii
inputs and correspondingly send the message to the window to print the
non-ascii characters as well. Below is the picture of how the
non-ascii inputs are considered and printed onto the window.
The solution spans across windows and mac platform and still in search
of a solution for the Linux platform. The solution implements key
scanning only upon existing valid ascii key was /_not_/ found and
assumes it as Unicode key and sends the event to event queue to be
processed as Unicode keys. Different formats are being used by
different platform implementation of Unicode. For ex., per the below
Unicode list, in the case of windows and mac, the key input can take
decimal values whereas on Linux it can only take the Code values.
On Linux, I was able to get the KeySym of Unicode keys but was unable
to fake the key event as there was no mechanism available for the
same(which sends the key event to window). Please let me know if there
is any such mechanism available to simulate Unicode key events on
Linux platform. Hence I think to raise a bug for the Linux platform
and close this JDK-8148344 bug.
Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
<http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/>
Thanks and regards,
Shashi
