For native platforms, we are using a scan code to key code conversion that should be sensitive to the current user’s keyboard layout.
The issue on Flash is that it appears that the translation between keyCodes and charCodes is set, regardless of the user keyboard layout. It is only when using TextField input that non-QWERTY layouts appear to be respected. I could be wrong?
Yeah, that’s been my experience so far. I guess I’m just confused about how the keycode-to-scancode conversion works to get this result, but the HTML5 target has the proper behavior for multiple layouts so I know it definitely DOES work.
Um, maybe I’m not following, but this sounds wrong.
I use the Colemak layout, which means the S and D keys have been moved. When I play a Flash game that offers WASD controls, I can’t place my fingers on the standard “inverted T” shape and expect things to work. Trust me, I’ve tried. (Though at least Colemak is better than Dvorak in this respect, since the keys are all still reachable with one hand. Back when I used Dvorak, I had to revert to QWERTY a lot more often.)
It seems that the letters are correct on Flash, but when tracing the charcode of shift+[any number], it still gives me the values from the English keyboard.
If it is not working in Flash Player, I wonder if we can programmatically call anything to determine the keyboard layout, and deduce these values ourselves?
This is what I was referring to before–it would work, it would just be time consuming. I’m also not sure if there is a way to determine the keyboard layout–other than guesstimating it by doing scanCode/keyCode comparisons on the letter keys 
Well, that’s what I mean. If we can get detect the keyCode/charCode discrepancy between the Q, W, E, R, T and Y keys, then we can determine safely between common layouts such as AZERTY or QWERTZ for correcting the values of shift keys
I feel like this is a very dangerous path to walk – from my googling it seems like there are at least four qwertz layouts, two azerty layouts, and TWENTY NINE qwerty layouts. That’s a lot of special cases.
Still, short of using a TextField for all input events, we may be able to derive more accurate shift-key values if we have some programmatic way of determining the relationship between key codes and char codes on Flash
Do we know why TextFields are correct for every keyboard layout? Or is that an Adobe secret?
They must use a different mechanism for keyCode/charCode than they do for text input. It probably has to do with IME support
What is IME support? The wikipedia page that comes up makes it sound like its mostly used for Chinese / Japanese characters
TextField in Flash Player supports complex text input, which includes Chinese, Japanese, Arabic (I think?) and other languages, where one key doesn’t necessarily equal one character
Ah, so you think that it getting the key values right is a side effect of that feature?
Yep, so on Flash Player, I think there are two options to improve support for Lime key codes:
What we have right now is incorrect, although imperfect, the second approach seems like the better one to me, for now, as a hidden TextField could cause a lot of problems (though that is what we do on HTML5)
How did you use the Textfield on HTML? My implementation caused a lot of problems, as keyboard events were not being dispatched to the stage any more, so they could not be picked up by other keyboard event listeners.
This in in the Lime layer, so we can use a hidden DOM input, then simulate focus events in the OpenFL layer. That’s why I wasn’t sure it would work well for Flash Player
I’m trying to test some lime scancode stuff…is there a dev version where the scancode issue is fixed? It’s marked as closed on the github but I’m just getting 0 for all my scancode traces.
public function new()
{
super();
// Assets:
// openfl.Assets.getBitmapData("img/assetname.jpg");
stage.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDown);
stage.window.onTextInput.add(onTextInput);
stage.window.onKeyDown.add(onKeyDownLime);
}
function onKeyDown(e:KeyboardEvent )
{
trace("Event charcode: " + String.fromCharCode(e.charCode));
}
function onKeyDownLime(k:KeyCode, m:KeyModifier)
{
trace("Lime keycode: " + k);
var scanCode:ScanCode = k;
trace("Lime SCANcode: " + ScanCode.fromKeyCode(k));
}
function onTextInput(s:String)
{
trace("Text input: " + s);
}Oh, it looks like the problem is it only works on native platforms. Will we be able to use this solution for Flash, then?
Theres also flash.system.Capabilities.language which could potentially make it easier to determine the keyboard layout–unfortunately it seems to be unimplemented (or else I’m just not triggering it correctly) because even when changing keyboards several times, it still only reports “en”.