stt@inmet (05/18/89)
They are called "representation clauses." In particular, the one to which you refer is an "address clause for an interrupt entry." There are in fact a number of compilers which support interrupt entries. However, the more critical issue is whether the operating system provides an interface which gives non-kernel code the chance to be informed when a key is typed. Unix systems generally provide "signals" for the Interrupt and Quit keys (often "^C" and "^\"). Getting a signal on any key is tougher. For the purposes of the original question, "raw" or "cbreak" mode would be adequate on Unix, but again, it depends on whether the Ada run-time-system supports these modes, or whether the user wants to "roll their own" input routines (presumably using pragma Interface). Similar capabilities exist in VMS, but the same caveats apply (need support in RTS or roll-your-own). Tucker Taft Intermetrics, Inc. Cambridge, MA
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/22/89)
From article <124000045@inmet>, by stt@inmet: > Unix systems generally provide "signals" for > the Interrupt and Quit keys (often "^C" and "^\"). > Getting a signal on any key is tougher. > For the purposes of the original question, "raw" or "cbreak" > mode would be adequate on Unix, but again, it depends > on whether the Ada run-time-system supports > these modes, or whether the user wants to "roll their own" > input routines (presumably using pragma Interface). This is an area in which a "secondary standard" (maybe even a new predefined package!) is badly needed. There should be some means whereby the application writer can, in a straightforward and machine-independent way, either call some function which will return an object whose state will indicate which key was pressed (note: this is NOT the same as returning ESC and then returning some other character(s) on succeeding calls, the entire sequence of which represents an arrow key or something of that nature...), or establish a task entry which will be called when the next keystroke occurs, with a similarly "high-level" interface. This will probably require a larger carrier space than CHARACTER provides (unless 9X upgrades CHARACTER to ISO Latin 1 (aka 8-bit ASCII)), but it's something which definitely needs to be built up to an appropriate level of abstraction. Bill Wolfe, wtwolfe@hubcap.clemson.edu
dik@cwi.nl (Dik T. Winter) (05/22/89)
Talking about machine independent: In article <5549@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > This is an area in which a "secondary standard" > (maybe even a new predefined package!) is badly needed. > > There should be some means whereby the application writer > can, in a straightforward and machine-independent way, > either call some function which will return an object whose > state will indicate which key was pressed But how then does the application writer know which key means what? (Oh yes, I see it: on this keyboard key 17 is 'A', on that keyboard key 17 is uparrow.) Moreover, on many systems this is impossible. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/22/89)
From article <8131@boring.cwi.nl>, by dik@cwi.nl (Dik T. Winter): >> There should be some means whereby the application writer >> can, in a straightforward and machine-independent way, >> either call some function which will return an object whose >> state will indicate which key was pressed % % But how then does the application writer know which key means what? % (Oh yes, I see it: on this keyboard key 17 is 'A', on that keyboard % key 17 is uparrow.) Moreover, on many systems this is impossible. The keys are generally labeled; e.g., the 'A' key will be labeled A. The function then returns some object whose value indicates an 'A'... Bill Wolfe, wtwolfe@hubcap.clemson.edu