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 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> > 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. > 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 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
