It might be interesting to note how these keys are handled by PCs. The
PC has always handled the cursor-keypad keys differently from standard
character codes. For example, in Windows there is a "virtual key code"
associated with each cursor-keypad key (as well as for other keys) and
you get such codes in WM_KEYDOWN messages. If you just pass a
cursor-keypad WM_KEYDOWN message onto the default handler, it does
nothing, and nothing further happens (except that a corresponding
WM_KEYUP message will come along). It's your privilege to do something
meaningful with the virtual key code or ignore it. However if you
ignore the WM_KEYDOWN for a regular character code, e.g., that for 'A',
the system will, in turn, send a WM_CHAR code with the desired character
code (on NT it's Unicode!). This approach works well and avoids the
problem of creating new Unicode values which then have to have both a
presentation form as well as a function.
It is handy to have a presentation-only form to use in documenting
keyboards. For this purpose, Ken lists some useful codes.
One place where character codes could come in handy is in writing
scripts that drive the keyboard, much as player-piano scrolls play the
piano. Ordinarily such scripts are written with a "higher-level" escape
syntax superimposed on top of the plain text.
Murray
> -----Original Message-----
> From: kenw@sybase.com [SMTP:kenw@sybase.com]
> Sent: Tuesday, July 29, 1997 4:16 PM
> To: Multiple Recipients of
> Subject: Re: unicode values for keyboard keys?
>
> Michael Baldwin asked:
> >
> > are there any unicode values defined for the common keys on
> keyboards:
> >
> > home, end, insert, page up/down, left/right/up/down arrow
> > function keys 1-12, print, scroll, pause
>
> There is a rather haphazard collection of such things:
>
> See the arrows section of the Unicode Standard, where a number of
> the arrows are identified with keyboard functions and/or keys,
> although
> the semantic for these characters is not constrained to mean *only*
> those functions or keys:
>
> U+2190..U+2193 basic directional arrows, associated with cursor
> movement
> U+21A1 = form feed
> U+21B4 = line feed
> U+21B5 = carriage return
> U+21B8 = home
> U+21B9 = tab/shift tab
> U+21DE = page up
> U+21DF = page down
> U+21E4 = leftward tab
> U+21E5 = rightward tab
> U+21E7 = shift
> U+21EA = caps lock
>
> The problem is that these arrows really only represent their shapes,
> but
> these shapes are conventionally associated with many of these
> functions
> on keyboards. For example, U+21B9 is the character for the glyph often
> found printed on a Tab key on a keyboard (including the one I am using
> now), but it isn't a single function. The glyph is mnemonic for the
> fact
> that there are two different functions associated with the key,
> depending
> on whether the shift key is depressed when I tab or not. And in any
> case, this is different from U+0009 HORIZONTAL TABULATION
> (representing the
> real TAB character itself) and U+2409 SYMBOL FOR HORIZONTAL TABULATION
> (representing an arbitrary paste-your-graphic here character for
> symbolizing
> a TAB character, rather than the TAB character itself).
>
> Then there is another set of keyboard symbols, buried among the
> miscellaneous technical symbols:
>
> U+2318 = command key
> U+2324 = enter key (on different keyboards than U+21B5 !)
> U+2325 = option key
> U+2326 = delete to the right (i.e. delete)
> U+2327 = clear key
> U+232B = delete to the left (i.e. backspace)
>
> And you should know that there is another passle of these animals
> being herded through the ISO stockyards even now, to round out the
> collection of keyboard symbol glyph characters to match one or
> more ISO keyboard standards, including another 8 arrow shapes,
> and another 20 misc. shapes, including everything from continuous
> underline to pause to undo to help and screen print.
>
> Nobody has yet proposed separate symbol characters for the
> 12 functions keys (whew!)--I guess because you can represent
> them by "F1", "F2", etc.
>
> >
> > for systems that return a unicode stream for keyboard input, it
> would
> > be nice to have well-defined unicode values to return for them.
> > glyphs could be defined for them as well. but if they exist
> already,
> > then that would be even better...
>
> I wouldn't recommend encoding another set of characters
> just for mapping to keyboard return codes. This is, in fact,
> an excellent use of private-user-space. The problem with trying to
> standardize keyboard return codes as a set of standard
> characters is that there are so many different keyboards
> with so many different drivers specialized in so many ways.
> What works for a typical PC keyboard working on a Windows
> system won't be the same as what a typical Macintosh keyboard
> requires. Or what about the "Stop", "Props", "Front", "Open",
> "Find", "Again", "Undo", "Meta", "Compose", and "Alt Graph"
> keys on my Solaris workstation keyboard? Or who would like to do the
> work to specify mappings for the Data General editing keys or
> for 3270 terminal return codes or ... ?
>
> --Ken Whistler
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT