Mitch.Bradley@ENG.SUN.COM (05/30/91)
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? Mitch.Bradley@Eng.Sun.COM
milan@MJM.XYPLEX.COM (Milan Merhar) (05/30/91)
Mitch Bradley suggested: > 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 STANDARD SYSTEM that doesn't throw those "*@$%??!" implementation- 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?
NER034@PRIME-A.TEES-POLY.AC.UK (05/31/91)
Mitch Bradley writes: > 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. Mitch, This sounds like such a good idea that there is simply no chance of getting it past the TC ! Peter Knaggs +-----------------------------+-----------------------------------------------+ ! School of Comp. & Maths., ! Janet: NER034 @ uk.ac.tees-poly ! ! Teesside Polytechnic, ! Bitnet: NER034 % tp.ac.uk @ UKACRL ! ! Middlesbrough, ! Internet: NER034 % tp.ac.uk @ cunyvm.cuny.edu ! ! Cleveland, England. TS1 3BA ! Uucp: NER034 % tpoly.ac.uk @ ukc.uucp ! !-----------------------------+-----------------------------------------------! ! It is not enough to do the right thing; one must also do it the right way. ! +-----------------------------------------------------------------------------+
UNBCIC@BRFAPESP.BITNET (05/31/91)
I, too, think that EKEY can be eliminated.
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET