Xref: utzoo comp.sys.ibm.pc.misc:5390 comp.os.msdos.programmer:2757
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!netcom!resnicks
From: resnicks@netcom.UUCP (Steve Resnick)
Newsgroups: comp.sys.ibm.pc.misc,comp.os.msdos.programmer
Subject: Re: help!  dos(?) is grabbing half my alt keys
Message-ID: <20465@netcom.UUCP>
Date: 9 Jan 91 22:04:30 GMT
References: <1991Jan7.230518.25949@uunet!unhd> <y5sgV1w163w@phoenix.com>
Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest}
Lines: 46

In article <y5sgV1w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
>
>rg@msel.unh.edu (Roger Gonzalez) writes:
>
>> In Turbo C++ version 1.0:
>> 
>> #include <conio.h>
>> #include <stdio.h>
>> main()
>> {
>>     int c, done;
>> 
>>     done = 0;
>>     printf("Hit a key, <esc> to quit\n");
>>     while (!done) {
>>         c = getch();
>>         printf("keyboard scan code 0x%02x\n", c);
>>         if (c == 27)
>>             done = 1;
>>     }
>> }
>> 
>> Simple, right?
>> 
>> 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:
>> keyboard sc
>
>   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.

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. 

Hope this helps ....

Steve