Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.
Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, September 13, 2017 5:22 AM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>; Semyon Sadetsky <semyon.sadet...@oracle.com>; awt-dev@openjdk.java.net Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. Hi, Shashi. One initial question: What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used? On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote: > Hi, I have updated the Webrev to accommodate the comments and here is > the new Webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/ > > I have separated the /_Unicode_/ keys input via java robot as a new > set of /_public_/ api’s (this is in similar fashion as how the > platform offers the Unicode keys input into the system) and this has > been tested on all the platforms using the test file similar to the > attached file in the bug. A more proper test file would be put for > review in the subsequent reviews. > > Thanks and regards, > > Shashi > > *From:* Sergey Bylokhov > *Sent:* Wednesday, August 30, 2017 2:33 AM > *To:* Shashidhara Veerabhadraiah > <shashidhara.veerabhadra...@oracle.com> > *Cc:* awt-dev@openjdk.java.net > *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should > be able to use extended key code characters as ? ? ?. > > Hi, Shashi. > > This is part of this fix, to figure out how it will work for external > applications. As you said this functionally can be useful for an > onscreen keyboards, which virtually can have any possible keys, but we > should check how the applications will react on such keys: > - Will the application get some kind of keyPress/Release? > - Will the application get some keyCode for such event? > - Is it possible to get autorepeat for such keys?(between > press/release) > > Depending from the answers above we can enhance existed robot API or > provide a new one: > like Robot.keyType(char)/etc > > ----- shashidhara.veerabhadra...@oracle.com > <mailto:shashidhara.veerabhadra...@oracle.com> wrote: >> > >> > >> > > Hi Sergey, I was only able to add short cut keys in the Microsoft word > but not as a system wide short cut key. There was no mechanism that I > could find to add a short cut key for a Unicode char!! Can you please > tell me the steps to do the same if you are aware of? > > Thanks and regards, > > shashi > >> > > *From:*Sergey Bylokhov >> *Sent:* Tuesday, August 22, 2017 8:34 PM >> *To:* Shashidhara Veerabhadraiah >> <shashidhara.veerabhadra...@oracle.com > <mailto:shashidhara.veerabhadra...@oracle.com>> >> *Cc:* awt-dev@openjdk.java.net <mailto:awt-dev@openjdk.java.net> >> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should >> be > able to use extended key code characters as ? ? ?. > > Hi, Shashi. >> Can you check how this Robot API will work when the application will have a >> shortcut for such key? Will such shortcuts will work after this fix? >> >> ----- shashidhara.veerabhadra...@oracle.com > <mailto:shashidhara.veerabhadra...@oracle.com> 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/ > > Thanks and regards, > > Shashi > -- Best regards, Sergey.
