🚀 go-pugleaf

In article <20465@netcom.UUCP> resnicks@netcom.UUCP (Steve Resnick) writes:
>In article <y5sgV1w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
>>
>> In some other article, I wrote:
>>> 
>>> Why is it that the second half of the 2 byte sequence transmitted by
>>> certain alt keys sometimes gets absorbed and used by DOS?  For example,
>>> <alt>R transmits the sequence 0x00 0x13.  Every now and then, the output
>>> will get hung as if the 0x13 (which is ^S) was typed:
>>
>>   You are probably getting caught by the I/O statement (printf) letting
>>DOS look at the keys, or by TurboC looking. The TurboC docs say something
>>about control-C checking occuring during I/O.
>>
>>   Try doing an immediate second getch() if the first getch() returns 0.
     See below
>
>Turbo C's getch function calls MS DOS function 8, keyboard input without echo.
>This function checks for special MS DOS characters (so ^S will pause output
>and ^P will toggle printing). If you want to read an extended ASCII key
>stroke, you need to call getch twice. The first call to getch will return
>a 0 on an extended ASCII character, the next call will get you the extended
>keystroke. 
Not sufficient

I got many responses, but enough of them were still suggesting using
getch(), that I thought I'd share the best workaround I received:

Although there is a slightly better chance that if I do a second getch()
immediately (without going all the way around the loop again) I'll be
able to grab the 0x13's or 0x10's before DOS.  There is still no guarantee.
As was pointed out to me, by the time the character gets to the stdio
level routines, everyone and their brother has had a chance to poke and
prod at it.  A better fix is to use the bioskey() routine, which lets
you beat everyone to the punch.  bioskey(0) returns a two byte packet
which for a normal character is a combination of the scan code and the
ascii value.  For an extended character, like <alt>-R the low byte is 0x00,
so the result is a short int like this: 0x1300.  bioskey(1) is similar
to the kbhit() function, and bioskey(2) returns a bitpacked number
that contains the status of the shift keys.

Thanks for all the advice, good and bad. :-)

-Roger


-- 
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsgar W. Dijkstra 
rg@[msel|unhd].unh.edu        |  UNH Marine Systems Engineering Laboratory
r_gonzalez@unhh.bitnet        |  Durham, NH  03824-3525