Lime keyboard event confusion

Lime
#21

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?

#22

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 :confused:

#23

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

#24

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.

#25

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

#26

Do we know why TextFields are correct for every keyboard layout? Or is that an Adobe secret?

#27

They must use a different mechanism for keyCode/charCode than they do for text input. It probably has to do with IME support

#28

What is IME support? The wikipedia page that comes up makes it sound like its mostly used for Chinese / Japanese characters

#29

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

#30

Ah, so you think that it getting the key values right is a side effect of that feature?

#31

Yep, so on Flash Player, I think there are two options to improve support for Lime key codes:

  1. Have a hidden Flash TextField, and give it focus. Use that for translating the values
  2. Find a programmatic way to determine non-shift keyCode/charCode relationships, and use that to derive the most likely shift-key values

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)

#32

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.

#33

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

#34

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);
}
#35

Oh, it looks like the problem is it only works on native platforms. Will we be able to use this solution for Flash, then?

#36

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