Adobe Air on Windows not responding to AltGR to enter hashtag # Square brackets [ ] etc in the GWizard

[XiaoShiZi]

Discussed in https://github.com/airsdk/Adobe-Runtime-Support/discussions/2364

^{Originally posted by **XiaoShiZi** December 18, 2022} Dear folks, Having trouble with GWizard not accepting the AltGr and hashtag or square bracket (# [ ] ) characters. Not able to enter them with the keyboard, even not by using the onscreen keyboard under windows 10. So getting deeper into the problem got me that GWizard uses the Adobe Air. Even after updating to the latest Adobe Air version give me still the same problem. Enter the keys in Notepad and any other windows program I get what I want to type like now @#{}[]Ú€ So this is certainly a problem coming from the Gwizard and underlaying AdobeAir not responding to these keystrokes with the correct symbols. As it doesn't accept AltGr I can't use the Ascii code neither to enter those symbols. Any suggestion on what or how I can check and try to get the GWizard responds to the correct key input? Have updated all drivers and running latest version of the Win10 64 bit. Is there a way to check the key input under Adobe Air? And most importantly how to get it working in GWizard. Contacted Bob Warfield from GWizard but he can't reproduce the trouble I have so I'm digging deeper. Kind Regards, XiaoShiZi

[XiaoShiZi]

Additional Information on a workaround:

This is due to the keyboard language settings being different from English. Reported back to GWizard. So add the Keyboard input language English United States and get the OnScreen keyboard to so you can check witch key to press for the corresponding character. Still don't know why even the OnScreen keyboard didn't spit out the corresponding hashtag etc. into the program. So could be this is a caveat for AdobeAir to get internationalization into the keyboard settings better sorted out ;-)

Looking forward to the deeper knowledge and correct handling to prevent this for future programs.

Kind regards,

XSZ.

[ajwfrost]

Hi - it depends a little perhaps on how the GWizard application is handling key events... we had a similar issue with another client a while ago who were doing some interpretation themselves based on scan codes etc and ended up with some localisation issues like this. If you just have a listener for KeyboardEvent in AIR and check the values of keyCode vs charCode, you could see e.g. in GB keyboard shift-2 would give key code 50 and char code 34 (and the char code is ascii so this is " which I see on my keyboard). If I change to a US keyboard, shift-2 still gives key code 50, but now is char code 64 (ascii for @).

From AIR's perspective, these are showing up properly when we draw them via the char code values and when they automatically are added into a text field. So it may just be that GWizard is checking the key code values instead and missing the fact that different codes can be used for different things? or something similar perhaps...?

If you let us know the keyboard input language you were using and then what keyboard combinations you were using (and what characters you were then expecting) we can double-check this in AIR but I hadn't heard about an issue like this before..

thanks

[XiaoShiZi]

Dear ajwfrost @ajwfrost thanks' for your reply. Meanwhile I got closer to the origin of the cause. Anytime there's a keyboard setting that needs the AltGr combination in it GWizard (the CNC G-code simulation program) wouldn't handle it correctly. So it must be like you say that the handling is incorrectly implemented at the moment. I was using the Dutch Belgian keyboard setting in witch you have to press the AltGr+3 to get the # hashtag or the AltGr+^ to get [ Square bracket. The characters on th ekey are (3"#) or (¨^[) or ($*]) Screenshot of the key combo's to be used by the AltGr key

Opposed to the Eng United States Keyboard layout

Where only the Shift key to be used to get the []{}# characters. Kind regards and thx for helping us getting this corrected ;-)

XSZ