🚀 go-pugleaf

In article <1990Feb9.000950.11693@druid.uucp> darcy@druid.UUCP
 (D'Arcy J.M. Cain) writes:

> In article <1262@srhqla.SR.COM> tcm@srhqla.SR.COM (Tim Meighan) writes:
>>
>> [My sample code with mistake]
>>

> Hmmm.  Seems to only allow for function keys to be entered.  Regular
> keys will return -1.  Also 197 isn't the best choice.

Arg!  He's absolutely right, there is a misplaced closing brace.
It should have been:

	if(kbhit())
	{
		if((c = getch()) == 0)
		{
			c = (getch() + 197);
		}
		return(c);
	}
	return(-1);

I chose 197 because it makes F1 return a value of 256, F2 return 257, etc.
D'Arcy's method (shifting) is better at producing faster machine code.

Most keyboards produce an ASCII NUL (0) value when the user types CTRL-@.
This normally causes a BREAK to occur, but is something that can be
intercepted.  This raises a really interesting side point: if you redirect
the BIOS break handler vector to your own code, then it is possible to pass
the single 0 keycode back into get_key() via the initial getch() function.
Therefore, your program will hang at the second getch() call, since we're
assuming here that an initial 0 MUST indicate that a second key is waiting
in the buffer, which in this case is not so.

There are different ways to avoid this, such as having your application  
"fake" the extra keycode in its break handler.  It seemed "correct" to me
to use a NUL (0) since that is what the original ASCII control code was
anyway.   Which means that, for me, get_key() CAN return a 0 code, which
tells my application that the user attempted to break out of the program.

This is why I return a -1 to mean "no key pressed."  However, D'Arcy is quite
right that in many cases (where break traps aren't set up by the application)
a 0 code is never going to make it to the get_key() function, so it is
the faster and more intuitive way to indicate "no key pressed."

Tim Meighan