rg@msel.unh.edu (Roger Gonzalez) (01/08/91)
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
Also, <alt>Q, which transmits 0x00 0x10 uses the 0x10 as the ^P and
turns on parallel printer echoing.
There are probably others that do magic things as well.
Borland's tech support said to grab some vector or another; I haven't
looked into this avenue yet because it seems like an overkill solution
to a simple problem.
Please help me! This was supposed to be quick and dirty!
(email if possible)
-Roger
(a unix programmer serving time in dosland)
--
"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-3525stanley@phoenix.com (John Stanley) (01/09/91)
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.
resnicks@netcom.UUCP (Steve Resnick) (01/10/91)
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
rg@msel.unh.edu (Roger Gonzalez) (01/11/91)
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