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?