Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.sys.atari.st Subject: Re: Ctrl-C Keywords: VBL Message-ID: <607@philmds.UUCP> Date: 19 Aug 88 11:02:58 GMT References: <7620@boring.cwi.nl> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 57 In article <7620@boring.cwi.nl> steven@cwi.nl (or try mcvax!steven.uucp) writes: >Gemdos only registers a ctrl-c when something is written to the >screen, or read from the keyboard (and then only non-raw I/O). Gemdos ctrl-c's are so to say synchronous, while you'd like them to be asynchronous. [some lines deleted]... >So it seems to me that the only way of allowing ctrl-c when you're not >doing I/O is the following: > > If output is not redirected: periodically write a NUL; > this seems to have no effect on the screen, but does > generate a ctrl-c trap if one has been typed. (If the > output is redirected, the NUL's end up in the file.) > > If output is redirected, but input is not redirected: > periodically read and buffer the input yourself. > You could also do this in the above case. > > If both are redirected: read and discard raw characters from > the keyboard, checking for ctrl-c. > >My question is: does anybody know of a simpler method? As you have indicated more or less, you have to do a lot of work yourself. Having to distinguish between redirection and no redirection, as well as writing null characters sounds terrible to me. Take a large calculation - little I/O - ; you would have to add Cconws's or similar stuff throughout the code (not too few so you have a convenient response time, not too much so the performance won't suffer). A year or so ago I had the same problem; solved it by using a VBL routine. The solution was to check for control C in the keyboard input buffer; if this was found, the return address on the supervisor stack (pointing mostly in the user program or somewhere in the O.S.) was made to point to a Pterm GEMDOS call. The routine distinguished between user and supervisor mode and whether the program at hand was the desktop or something like that. It worked most of the time; there were some problems when trying to interrupt a GEMDOS call or something. I didn't take the effort to solve this; maybe it's simple when taking a fresh look at it again. The main advantage is that control-c's are asynchronous, and your program does not have to be cluttered by dummy console output garbage, or other magic if raw I/O is being used. I could post/mail what I have now, or try to solve the last bugs and post it to the binaries/sources groups (will be an AUTO folder program). Anyone interested? Leo. B.T.W. It might also be very handy to disable/enable control C's at will (for example by keyboard control: after pressing some magic key, or by program control: after executing a special trap). This could also fix the problem of disabling ^C for inexperienced users hitting ^C by accident whilst in the GEMDOS readline function (0xa I thought it was). Any suggestions?