sq.h changes, grabbed reserved field in sqKeyboardEvent
Andreas Raab
andreas.raab at gmx.de
Wed Mar 29 22:18:49 UTC 2006
John -
John M McIntosh wrote:
> In our work with Sophie we became aware of a shortcoming in how keyboard
> events are created and what data they contain and what data is needed
> to transform keyboard command on various obscure European keyboards
> into meaningful interactions within Tweak and other important
> applications like Sophie.
What exactly is the shortcoming that you are referring to?
> In the past on the macintosh and we believe on Windows the data coming
> up as a result of a keystroke was
>
> key down
> charCode: a magic number mapping to a key on the keyboard,
> different between mac/windows
> pressCode the utf-32 value of the key pressed
> additionalData the macroman value of the key pressed
This won't work at all on Windows. There is no way for me to generate
either a utf32 or a macroman value for "the key pressed". All that's
reported is a virtual key code which is arbitrarily assigned by Windows,
e.g., one of the VK_XXX constants.
> key char
> charCode the macroman value of the key pressed
> pressCode the utf-32 value of the key pressed
> additionalData a magic number mapping to a key on the keyboard,
> different between mac/windows
And this won't work either on Windows, in particular not for
international keyboards. When keys are composed we get sequences like
"accent key down, accent key up, character key down, (composed)
character input, character key up". This happens on the Mac as well, for
example try pressing option-E first (you get keydown/keyup) and then e
(which gives you accent-e). So there is not necessarily a correspondence
between a key and its ascii value.
> This preserves the existing behaviour, but adds the ability to better
> support non-usa keyboards and character sets.
Could you please first state the problem before proposing a solution ;-)
Cheers,
- Andreas
More information about the Vm-dev
mailing list