KEY and EKEY 
Author Message
 KEY and EKEY

My current thinking is that EKEY could be eliminated, and KEY should
be defined to return a *number*, not a character.

There should be a constant (or perhaps an environment query) for
MAX-CHARACTER .  If the number returned by KEY is less than MAX-CHARACTER# ,
then it is a character in the implementation-defined character set.  If the
number is outside that range, it represents an event (function key, whatever)
in an implementation-defined event space.  The crucial point is that the
set of valid characters is well-defined subset of the set of events, and
it is possible for a program to test whether or not the thing returned
by KEY is or is not a character.  Presumably, a standard program would
discard non-character events, or pass them to a system-specific event
handler routine.

What do you folks think about this?




Mon, 15 Nov 1993 10:00:13 GMT  
 KEY and EKEY
Mitch Bradley suggested:

Quote:
> My current thinking is that EKEY could be eliminated, and KEY should
> be defined to return a *number*, not a character.
> There should be a constant (or perhaps an environment query) for
> MAX-CHARACTER .  If the number returned by KEY is less than MAX-CHARACTER# ,
> then it is a character in the implementation-defined character set.  If the
> number is outside that range, it represents an event (function key, whatever)
> in an implementation-defined event space.  The crucial point is that the
> set of valid characters is well-defined subset of the set of events, and
> it is possible for a program to test whether or not the thing returned
> by KEY is or is not a character.  Presumably, a standard program would
> discard non-character events, or pass them to a system-specific event
> handler routine.

I agree completely.

I'm sure someone will ask the question, so let's get it over with:
 "If I'm so careful to write a STANDARD PROGRAM, why can't I expect a

 specific input characters at me when I use the standard input word?"

My answer, only slightly tongue-in-cheek, is "a conservatively-
designed program must be very liberal in the input data it accepts."
In other words, the _programmer_ remains responsible for
bullet-proofing, NOT the machine.  After all, the machine doesn't know
if the program is doing data-entry or is pushing a cursor around; all
it knows is that sometimes the user types on the keys with letters,
and other times on the keys with funny stuff on the tops.

I am quite sure that other options to the "KEY" problem exist,
including making KEY "state smart" where "state=input_mode", and
vectoring KEY to be either "GET-STANDARD-KEY" or "GET-ANY-KEY". As
with the battles over "TICK", equally reasonable arguments can be
raised about standardizing the "clever" word, or the "stupid" words
underlying it.  Mitch suggests standardizing the lower-level word, and
giving the user the system information needed to build the
higher-level word, if they wish to.  Why not?



Mon, 15 Nov 1993 23:54:32 GMT  
 KEY and EKEY
I, too, think that EKEY can be eliminated.

                              (8-DCS)
Daniel C. Sobral



Tue, 16 Nov 1993 21:34:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. KEY and EKEY

2. portable definitions for KEY and EKEY?

3. Key and EKey

4. KEY , EKEY , AND EKEY>CHAR

5. IDLE-EKEY?

6. EKEY in gforth in DOS

7. EKEY in gforth for linux?

8. EKEY>CHAR in Win32Forth

9. EKEY and double numbers

10. EKEY part 3 of 3

11. EKEY part 2 of 3

12. EKEY part 1 of 3

 

 
Powered by phpBB® Forum Software