weiss@theory.lcs.mit.edu (Paul G. Weiss) (01/26/91)
I have noticed discrepancies when using KbdCharIn between my program running in a text window or when it runs full screen. In both cases the keyboard is in binary mode and the calls to KbdCharIn have the IO_WAIT parameter set and the keyboard handle is 0. Discrepancy #1: When I type control-q, the KbdCharIn function returns with the proper ascii and scan codes when running full-screen, but the character is ignored when running in a text window. Discrepancy #2: I set up a signal handler for control-c and control-break. The signal handler simply sets a flag, acknowledges the signal and returns. Then, when I type either control-c or control-break, when the program is running full screen the KbdCharIn call returns with error code 0x5f, which is "System call interrupted". When the program is in a text window the flag is set, but the call does not return until after I type the next key. Question: Is this the correct behavior or is there a bug in the text window software? I am really more concerned with #2 than with #1. My goal is to restart my program's main loop when control-c or control-break is typed. I realize that my signal handler could longjmp back to my main loop but I was worried about leaving the Kbd system in an inconsistent state. Is it OK to do this? -Paul