| Top | |
|
|
|
| #define | keycode_Unknown |
| #define | keycode_Left |
| #define | keycode_Right |
| #define | keycode_Up |
| #define | keycode_Down |
| #define | keycode_Return |
| #define | keycode_Delete |
| #define | keycode_Escape |
| #define | keycode_Tab |
| #define | keycode_PageUp |
| #define | keycode_PageDown |
| #define | keycode_Home |
| #define | keycode_End |
| #define | keycode_Func1 |
| #define | keycode_Func2 |
| #define | keycode_Func3 |
| #define | keycode_Func4 |
| #define | keycode_Func5 |
| #define | keycode_Func6 |
| #define | keycode_Func7 |
| #define | keycode_Func8 |
| #define | keycode_Func9 |
| #define | keycode_Func10 |
| #define | keycode_Func11 |
| #define | keycode_Func12 |
You can request that the player hit a single key. See Character Input Events.
If you use the basic text API, the character code which is returned can be any value from 0 to 255. The printable character codes have already been described. The remaining codes are typically control codes: control+A to control+Z and a few others.
There are also a number of special codes, representing special keyboard
keys, which can be returned from a char-input event. These are represented
as 32-bit integers, starting with 4294967295 (0xFFFFFFFF) and working down.
The special key codes are defined in the glk.h file.
They include one code for return or enter, one for delete or backspace, twelve function keys, and one code
for any key which has no Latin-1 or special code. The full list of key codes
is included below.
Various implementations of Glk will vary widely in which characters the
player can enter. The most obvious limitation is that some characters are
mapped to others. For example, most keyboards return a control+I code when the tab key is
pressed. The Glk library, if it can recognize this at all, will generate a
keycode_Tab event (value 0xFFFFFFF7) when this occurs.
Therefore, for these keyboards, no keyboard key will generate a control+I event (value 9.) The Glk library will probably map many of the
control codes to the other special keycodes.
On the other hand, the library may be very clever and discriminate between
tab and control+I. This is
legal. The idea is, however, that if your program asks the player to
“press the tab
key”, you should check for a
keycode_Tab event as opposed to a control+I event.
Some characters may not be enterable simply because they do not exist.
Not all keyboards have a home or end key. A pen-based platform may not recognize any control characters at all.
Some characters may not be enterable because they are reserved for the
purposes of the interface.
For example, the Mac Glk library reserves the tab key for switching between different Glk windows.
Therefore, on the Mac, the library will never generate a keycode_Tab event
or a control+I event.
Note that the linefeed or control+J
character, which is the only printable control character, is probably not
typable. This is because, in most libraries, it will be converted to
keycode_Return.
Again, you should check for keycode_Return if your program asks the player
to “press the return
key”.
The delete and backspace keys are merged into a single keycode because they have such an astonishing history of being confused in the first place... this spec formally waives any desire to define the difference. Of course, a library is free to distinguish delete and backspace during line input. This is when it matters most; conflating the two during character input should not be a large problem.
You can test for this by using the gestalt_CharInput selector.
Glk porters take note: it is not a goal to be able to generate every
single possible key event. If the library says that it can generate a
particular keycode, then game programmers will assume that it is
available, and ask players to use it.
If a keycode_Home event can only be generated by typing escape control+A, and the player does not know this, the player will be lost
when the game says “Press the home key to see the next
hint.” It is better for the library to say that it
cannot generate a keycode_Home event; that way the game can detect the
situation and ask the user to type H instead.
Of course, it is better not to rely on obscure keys in any case. The arrow
keys and return are nearly certain to be
available; the others are of gradually decreasing reliability, and you
(the game programmer) should not depend on them. You must be certain to
check for the ones you want to use, including the arrow keys and return, and be prepared to use different keys in
your interface if gestalt_CharInput says they are not available.