#473 KEYBOARDVALUE returns the same codes for different keys

[Mike Cavender]

What am I missing?

When I use (keyboardon [keyDown] [keyUp]), some control keys do not return a unique keyboardvalue. For example:

The Insert key and the - key both return 45.
The Delete key and the . key both return 46.
The Right Arrow key and the ' key both return 39.

Is there a way to uniquely identify these keys?

[David Costanzo]

Ticket moved from /p/fmslogo/support-requests/8/

[David Costanzo]

From a quick look, I think you've found a bug. The keys should be different, and in fact they were different, but when I ported FMSLogo to use a different application framework, I messed up a few keys. If you find anymore, let me know as I have to fix them one-by-one.

Until a fix is available, you can use the version of FMSLogo that uses the original application framework

https://sourceforge.net/projects/fmslogo/files/FMSLogo/FMSLogo%206.35.0/fmslogo-6.35.0.exe/download

[Mike Cavender]

The Insert, Delete and Right Arrow keys are the only problem keys that I know of. The other control keys, while they return ASCII character values, are not in conflict. For example, the Left Arrow key returns a keyboardvalue of 37. ASCII 37 is a % character. But when the % key is pressed (shift-5), a keyboardvalue of 53 is returned.

Control key | ASCII | But the kbd returns
45 insert | -
46 delete | .
36 home | $ | 52 for shift 4 $
35 end | # | 51 for shift 3 #
33 page up | ! | 49 for shift 1 !
34 page down | " | 39 for shift ' "
38 up arrow | & | 55 for shift 7 &
40 down arrow | ( | 57 for shift 9 (
37 left arrow | % | 53 for shift 5 %
39 right arrow | '

[David Costanzo]

Thanks for the follow-up information, Mike.

The other control keys, while they return ASCII character values, are not in conflict. For example, the Left Arrow key returns a keyboardvalue of 37. ASCII 37 is a % character. But when the % key is pressed (shift-5), a keyboardvalue of 53 is returned.

I'm glad you mentioned this, because I think it highlighs a related bug in the documentation. I think the documentation for KEYBOARDVALUE needs to mention the difference in how it behaves when KEYBOARDOWN is given one input and when it's given two inputs. I think that KEYBOARDVALUE behaving differently depending on whether KEYBOARDDOWN was given one or two inputs makes it error-prone and confusing, but this implemented a long time ago, and FMSLogo continues to support it like this for compatibility with old programs.

When KEYBOARDDOWN is given one input, KEYBOARDVALUE is supposed to treat the keystroke as a character and return the ASCII values for each key. This corresponds to the WM_CHAR windows message. When KEYBOARDDOWN is given two inputs, then KEYBOARDVALUE is supposed to treat the keystroke as a key, so every key is supposed get a unique number and it doesn't matter if there's a 5 and a % painted on the same physical key, it's the same key. This corresponds to the WM_KEYDOWN windows message. The numbers themselves are called virtual key codes and were assigned by Microsoft long ago.

In short, % and 5 are supposed to have the same number when KEYBOARDON is given two values, because it's the same key. On non-US keyboards, the % and 5 may be on different keys, but the "5" key will always return the same number. In contrast, when KEYBOARDON is given one input, then the character represented by the key is returned, so whether it was a 5 or a % (Shift+5) is returned.

The only conflicts that should exist when KEYBOARDDOWN is given two inputs are keys which the keyboard manufacturer duplicated for our convenience. For example, there are two Shift keys on my computer, but they do the same thing. Also, some small keyboards (like the one on my laptop) have a special "function" key that toggles the meaning of other keys. In this case, KEYBOARDVALUE outputs something different for Right Arrow and Function+Right Arrow (which becomes a page up), even though it's the same physical key.

I'll try to fix the original problem (incorrect numbers for some puntuation keys) and improve the documentation when I fix this bug.

[David Costanzo]

I have committed a fix for the problematic behavior and expanded the documentation to include the keycodes as well as an explanation of the difference in values between when KEYBOARDON is given one or two inputs (similar to what I wrote on this ticket). The fix will be available in FMSLogo 7.0, which has no expected release date. If you'd like a wxWidgets-based version that contains the fix, post back to this ticket and I'll attach a private build.

In my investigation, I found many keys which the wxWidgets version mapped inconsistently with the OWL-based version FMSLogo (and MSWLogo). Many of them were specific to a particular keyboard layout. In fact, all of the ones originally cited in this ticket are specific to a US keyboard layout. It's likely that on other keyboard layouts, a different set were mapped inconsistently.

I had implemented a platform-independent keycode mapping logic so that someday I could port FMSLogo to non-Windows operating systems (like Mac or GNU/Linux) and have a reasonable expectation that FMSLogo programs would behave consistently. However, wxWidgets simply does not provide enough information to do this correctly across keyboard layouts and it might be impossible to do so on all platforms. Since FMSLogo may never be ported to a non-Windows operating system, but it is used on Windows with non-US keyboards, I've decided to use Windows-specific logic on Windows to guarantee compatibility with MSWLogo. After the fix, the wxWidgets version derives the key codes from the same source as the OWL-based version and MSWLogo.