[Laszlo-dev] Keyboard mystery [Was: Re: For Review: Change 20090602-bargull-GPN Summary: DHTML: add "updateControlKeys" to LzKeyboardKernel]

[André Bargull]

The only reliable information [0] for keydown/keyup events is the 
virtual key code [1]. For example, Firefox doesn't even support 
'charCode' for keydown/keyup (only keypress), or in ActionScript3 
'charCode' "Contains the character code value of the key pressed or 
released. The character code values are English keyboard values." [2].
But as it is only the English keyboard value, it's not a real help for 
us if we want to work with Unicode characters [3].
So we can only forward the keycode value from the kernel to LzKeys and 
let users cope with that information.

PS:
And there is also a bug in the mapping from keycodes to charcodes in the 
keyboard kernel for swf8 and dhtml (LPP-8241).



[0] let's say "almost" reliable 
https://bugzilla.mozilla.org/show_bug.cgi?id=413875
[1] http://www.mozilla.org/editor/key-event-spec.html
[2] 
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/events/KeyboardEvent.html#charCode
[3] e.g. shift+3 produces charCode=35 which is the character code for 
'#', but on a German keyboard shift+3 is the '§' character.


On 6/2/2009 7:14 PM, P T Withington wrote:
> 
> Something that is really a mystery to me is the internal protocol 
> between the keyboard kernel and LzKeys.  The kernel sends both a map of 
> the abstract keys that have changed state, _and_ the last physical key 
> code.  LzKeys maps the abstract keys to Flash physical keycodes, but if 
> it finds any abstract key that does not have a flash mapping, it uses 
> the platform physical code (which may or may not intersect with a Flash 
> physical code).  I'm guessing this was an attempt to make LZX code more 
> portable, but it's a pretty messy transformation (and looks to me like 
> it could cause some bugs because of the way the exception code works).  
> In the long run, it would seem like a better approach would be to create 
> a new set of LzKeys interfaces that dealt in abstract keys (as in 
> Unicode characters + strings to represent keys that do not correspond to 
> characters, like F1, Page-up, etc.) plus shift key states, which would 
> be uniform across platforms; and eventually deprecate the interfaces 
> that deal with Flash keycodes.
>