🚀 go-pugleaf

Greetings,
     I realize there have probably been atleast two buzillion (okay, I'm
exaggerating, one buzillion) questions relating to TOS' handling of the
<Control> C key and ways of disabling it, but I'm sure we could all use
a refresher course by now... :-)
    I have found that using the XBIOS (or are they BIOS??) functions
Cconws/Cconout to send information to the console is actually quite nice
for the application I am writing, since they allow the user to use
<Control> Q and <Control> S for flow control of the data on the screen
(whereas the "raw" output functions beginning with "B" do not.) The problem
is that as soon as the user enters a <Control> C the program is immediately
terminated with a status -32. Not nice.
     So it all boils down to this: has anyone found a LEGAL way (short of
redefining the keyboard, assuming TOS is looking for the ASCII and not the
scan code--redefining it would be inefficient for me anyway) of disabling
or trapping the key so that the program is not terminated? Moshe?
     Second of all I would like to know how programs like GEMSTART work
and if they can, in fact, work with the new ROMs without modification
(I have heard that the original GEMSTART won't work with the new ROMs.)
If you want to try something rather humorous, write a DA that Pexec's a
GEM program as soon as it runs. The application runs normally, puts up its
menu bar and all, but as soon as it does an evnt_multi the desktop magically
takes-over control once again which, of course, leads to several bombs if
you get tired of watching disk drive windows pop up from nowhere when you
click on the desktop and decide to select a menu item.
     Thanks in advance!

---------------------------------------------------------------------------
EEEeek! I went against my own                  Dan Wilga
credo and used a :-) !!!                       AndOr@UMASS.Bitnet
I'm so ashamed...                              Arpa? Just try and figure it
                                                 out!