* Machine-Independent Keystroke Input
@ 1989-05-26 12:16 Rick Conn
0 siblings, 0 replies; only message in thread
From: Rick Conn @ 1989-05-26 12:16 UTC (permalink / raw)
Re the recent discussion of this subject, the CAIS (Common
APSE Interface Set) proposes an interesting, altho somewhat involved, solution
to this problem. Reference DoD-STD-1838 (9 Oct 86), 5.3.8.19 describes
a machine-independent keystroke reader:
procedure GET (TERMINAL: in FILE_TYPE; ITEM : out CHARACTER;
KEYS : in out FUNCTION_KEY_DESCRIPTOR);
-- This procedure reads either a single character into ITEM or
-- a single function key identification number into KEYS from
-- the internal file identified by the input file handle TERMINAL.
-- If no character is available at the time of the call the
-- interface does not complete until a character becomes available.
This procedure is in package CAIS_SCROLL_TERMINAL_IO (and also in other
CAIS...TERMINAL packages). Type FUNCTION_KEY_DESCRIPTOR is limited private,
and the package contains many routines to manipulate objects of this class.
In particular, after calling this GET, the procedure FUNCTION_KEY_COUNT
is to be called:
procedure FUNCTION_KEY_COUNT (KEYS: in FUNCTION_KEY_DESCRIPTOR)
return CAIS_NATURAL;
-- Returns the number of function keys described in KEYS
FUNCTION_KEY_COUNT tells us if a character was returned in ITEM from
GET (returned value from FUNCTION_KEY_COUNT is 0) or if a function key
was returned (returned value is 1 since GET returns only one character or
one function key).
If FUNCTION_KEY_COUNT is 1, you can determine the function key's ID
by calling:
procedure GET_FUNCTION_KEY (KEYS: in FUNCTION_KEY_DESCRIPTOR;
INDEX : in CAIS_POSITIVE; KEY_IDENTIFIER: out CAIS_POSITIVE;
POSITION: out CAIS_NATURAL);
-- This procedure returns the identification number of a function key.
-- Used with the single-character GET procedure, POSITION = 0.
You would call GET_FUNCTION_KEY with an INDEX value of 1 in order to
return the proper KEY_IDENTIFIER.
Finally, with the KEY_IDENTIFIER, this procedure can be used to get the key's
name:
function FUNCTION_KEY_IDENTIFICATION (TERMINAL : in FILE_TYPE;
KEY_IDENTIFIER: in CAIS_POSITIVE) return
FUNCTION_KEY_NAME;
-- FUNCTION_KEY_NAME is of subtype STRING and is
-- implementation-dependent
The problem posed by Dik could be addressed by using a definition like this
and not allowing FUNCTION_KEY_NAME to be implementation-dependent.
In particular, I would like to see FUNCTION_KEY_NAME be an enumeration type
rather than a string (allowing, of course, for "other keys" not covered
by the "standard" enumeration values. For instance:
type FUNCTION_KEY_NAME is (PF1, PF2, -- others
CLEAR_SCREEN, INSERT, DELETE, -- others
UP_ARROW, DOWN_ARROW, -- others
-- even more others
SPECIAL);
function FUNCTION_KEY_IDENTIFICATION (TERMINAL : in FILE_TYPE;
KEY_IDENTIFIER: in CAIS_POSITIVE) return
FUNCTION_KEY_NAME;
-- FUNCTION_KEY_NAME is now an enumeration type
function SPECIAL_KEY_IDENTIFICATION (TERMINAL : in FILE_TYPE;
KEY_IDENTIFIER : in CAIS_POSITIVE) return STRING;
-- to be called when FUNCTION_KEY_NAME object is SPECIAL
This CAIS definition may be a good starting point. Part of the
reason for the complexity is that there is another GET which returns
a STRING or a group of FUNCTION KEYS (all keys pressed since the last call to a
GET). Regardless, I think the CAIS is a good thing to look at when
discussing machine-independent problems like this one.
Rick
-------
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~1989-05-26 12:16 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-05-26 12:16 Machine-Independent Keystroke Input Rick Conn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox