Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amdahl!amdcad!pepsi!ching
From: ching@pepsi.amd.com (Mike Ching)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Control-Break ignored in Turbo-C graphics mode....
Message-ID: <25159@amdcad.AMD.COM>
Date: 7 Apr 89 22:41:49 GMT
References: <89Apr4.202845edt.2759@godzilla.eecg.toronto.edu> <4212@ttidca.TTI.COM>
Sender: news@amdcad.AMD.COM
Reply-To: ching@pepsi.AMD.COM (Mike Ching)
Distribution: na
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 24

In article <4212@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes:
 >In article <89Apr4.202845edt.2759@godzilla.eecg.toronto.edu> lansd@eecg.toronto.edu (Robert Lansdale) writes:
 >}	I have a small problem trying to get Control-Break to be
 >}recognized while in graphics mode, using Turbo-C's Hercules BGI driver
 >}(version 2.0). I initially revector the control-break handler to my own 
 >}handler using the ctrlbrk(handler) command, which works fine while in text
 >}mode, but is ignored once I switch over to graphics. I assume the
 >}BGI driver is vectoring the interrupt to itself. Any suggestions?
 >
 >Does your graphics software spend much time in a tight loop?  I had a
 >similar problem with a mandelbrot program written in TC 2.0.  It would
 >ignore control-C interrupts until I put in some debug screen output.  Then
 >they worked just fine.
 >
I believe the control-c interrupts are checked during console I/O so
there needs to be getchar() and putchar() being executed somewhere
for the interrupt to be recognized. Any program not doing I/O would
also seem to ignore control-c. The debug screen output adds the I/O
necessary for the program to respond to control-c. The original poster
may be able to do something like add a keyboard test or print cursor
positioning commands occasionally to allow program to respond to
keyboard input.

Mike Ching