rawKeyDown slightly cooked

[Fraser Gordon]

Hi Richmond,

I'm typing this off the top of my head as I'm not in the office to confirm
this is exactly what is happening (hence the non-RunRev email address), but
here goes...

RawKeyDown is indeed raw but is a different meaning of "raw" from what you
are expecting - it isn't the key scancode from the keyboard hardware; it is
a number that uniquely identifies every character and non-character key.

For example, the control key generates a particular raw key code that is
the same regardless of how the keyboard is laid out. Similarly, the letter
A always generates the 'A' raw key code, regardless of whether you have a
QWERTY, AZERTY or some other layout.

The exact numbers generated for each raw key code are those specified in
the X11 standard so that is the place to look for mappings between
numerical values and key names. The reason that you sometimes see very
large-valued numbers is because Unicode codepoints that weren't originally
assigned X11 keycodes are assigned a raw key value of 0x10000000 (IIRC) +
their codepoint.

Given the above, "raw" in this case means "before any part of LiveCode has
had the chance to intercept and handle the key". For example, accelerator
combinations used to access menu items.

One case to think about is input methods that do not use physical input
devices, e.g various input method editors (IMEs) for Asian languages or
even the on-screen software keyboards used on mobile platforms - a scancode
does not make sense for these devices but a raw key event is still
generated (at least in some cases; I believe IME input skips raw key
handling currently, something that may change in the Unicode engine).

Another problem with getting scancodes is that the correspondence between
keystrokes and characters is not one-to-one; a dead-key accent plus a base
letter takes two keystrokes but may result in the engine only receiving one
(pre-composed) character from the operating system.

This, unfortunately, doesn't help much with your problem of producing
shortcuts based on physical key locations. One (admittedly poor) solution
might be to use shortcuts and accelerators based on symbols common to all
the keyboards you expect to use.

It is definitely one of the most frustrating aspects of dealing with
keyboard input that there is no good solution to the question of how to
assign keys to shortcuts; even if you avoid or overcome the problem of
making the symbols appropriate for the user's language, you can't guarantee
that they actually have the physical buttons that correspond to those
symbols.

I apologise for the wall of text that is this explanation but I guessed
that the "because..." part of "this doesn't work" is sometimes needed so
that it isn't assumed that the answer is "because we say so" ;)

-----

The TL;DR version for those who skipped the above is that raw key events
are symbols like Control, Tab, Backspace, A, etc rather than raw scan codes
from the keyboard hardware.

Regards,
Fraser
(hoping he hasn't gotten the above entirely wrong!)