Bogus keys on 3.0.0-beta

Haxe
#1

I got some bugs with charCode and keyCode on openfl.events.KeyboardEvent.KEY_DOWN. I tested it on Linux, I don’t know if other platforms behave the same.

This are the results of trace of event, as example I press A and NUMPAD_1:

On 3.0.0
A

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=65 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: charCode reported as Upper Case)

A after Shift:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=65 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=true

(note: OK)

A after CapsLock:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=65 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: OK)

NUMPAD_1:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=97 keyCode=97 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: OK?)

On “legacy”

A:

KeyboardEvent type=keyDown bubbles=true cancelable=true charCode=97 keyCode=65 keyLocation=1 ctrlKey=false altKey=false shiftKey=false

(note: OK)

A after Shift:

KeyboardEvent type=keyDown bubbles=true cancelable=true charCode=65 keyCode=65 keyLocation=1 ctrlKey=false altKey=false shiftKey=true

(note: OK)

A after CapsLock:

KeyboardEvent type=keyDown bubbles=true cancelable=true charCode=97 keyCode=65 keyLocation=1 ctrlKey=false altKey=false shiftKey=false

(note: charCode reported as Lower Case)

NUMPAD_1:

KeyboardEvent type=keyDown bubbles=true cancelable=true charCode=49 keyCode=65 keyLocation=1 ctrlKey=false altKey=false shiftKey=false

(note: keyCode reported as A, charCode differs from 3.0.0)

So, both versions are bugged or am I doing something wrong?

#2

What does Flash give you for these?

#3

With Flash capitals seems to be OK on both 3.0.0 and “legacy” (even Shift + A with CapsLock ON produces lower case as it suppose to).

The only thing is that NUMPAD_1 produces different results when switching NumLock On/Off (I’m not sure if its suppose to be this way):
charCode=0 keyCode=35 with NumLock ON
charCode=49 keyCode=97 with NumLock OFF

#4

I think that’s because it becomes the END key? Something like that?

#5

Yeah, but I’m not sure if its some sort of in-browser limitation, as on native targets keyCode should always be the same, no matter of NumLock, CapsLock, Shift etc. Correct me if I’m wrong :slight_smile:

#6

I think the goal of a key code is to return an ID for the key the keyboard sent to the computer. Using a different kind of keyboard layout, or a virtual keyboard could all change the meaning behind num lock and whether two keys share the same function, or especially what happens with a shift key.

The char code is then what ANSI value it corresponds to, but this is prone to fail for a lot of reasons. This is one reason for the separate text input events, which we still need to support (but will) as we pull it from SDL

I released a new version of OpenFL, just now, that does some improvements to the key codes, though. Some of the keys (such as dollar signs or question marks) should map properly on the new code, and there should be charCode values similar to the legacy SDL targets

#7

Thanks for your response @singmajesty, but it still doesn’t work right for me:

After update to 3.0.1:
A

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=97 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: OK)

A after Shift:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=97 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=true

(note: charCode reported as Lower Case)

A after CapsLock:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=97 keyCode=65 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: charCode reported as Lower Case)

NUMPAD_1:

KeyboardEvent type=keyDown bubbles=true cancelable=false charCode=97 keyCode=97 keyLocation=0 ctrlKey=false altKey=false shiftKey=false

(note: bad keyCode and charCode)

On “legacy” results didn’t change.

#8

Okay, I think I’ve got it :smile:

#9

In OpenFL Next, the keyLocation is also not reported correctly anymore! In Legacy, it was 1 for most keys, and then 0 for the keys for which there is a right one (shift, alt, command). This is visible in madneon’s traces.

I’ll see if I can fix that in the Stage class.

#10

@singmajesty I see it’s a little complicated. Legacy Stage had a bunch of event flags, including one for the key being located on the right side. So the KeyboardEvent.keyLocation could either be 1 for left/default keys, and then 0 for right keys.

For Next, if I use the openfl.ui.KeyLocation enum, LEFT = 1 and RIGHT = 2, so there would be an inconsistency with Legacy right (0) and Next right (2). Should I modify the enum so that existing implementations don’t break?

Also, I’m not sure now how to check for the location, since Next Stage doesn’t have the event flags anymore.

#11

I believe I’m getting somewhere with detecting the location! But I’d still like some direction regarding the Legacy/Next right inconsistency.

#12

It looks like the newer enum values match Flash:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/KeyLocation.html

If possible, I’d like to keep it compatible with it :slight_smile:

#13

OK :slight_smile: It’ll just mean that projects from v2 (and earlier?) which relied on Left=1 and Right=0 will break with the update. So anybody who has made a custom input layer using that will have to make some changes.

I’ll make a pull request shortly :slight_smile:

Update: Pull request! https://github.com/openfl/openfl/pull/712

1 Like