Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!midway!gsbsun!valley
From: valley@gsbsun.uchicago.edu (Doug Dougherty)
Newsgroups: comp.os.msdos.apps
Subject: Re: Desqview and Ctrl/Alt/Del
Keywords: desqview ctrl/alt/del trapping programming
Message-ID: <1991Apr20.125614.22252@midway.uchicago.edu>
Date: 20 Apr 91 12:56:14 GMT
References: <1991Apr19.174531.15849@midway.uchicago.edu> <1991Apr20.032202.16205@cs.cmu.edu>
Sender: news@midway.uchicago.edu (NewsMistress)
Organization: University of Chicago
Lines: 27

ralf+@cs.cmu.edu (Ralf Brown) writes:

>In article <1991Apr19.174531.15849@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes:
>}But the real question is, "Suppose you have an application that does its
>}own C/A/D trapping and run it in a DV window.  DV does its own C/A/D handling,
>}and the question is which one overrides.  Answer: DV."
>}
>}My question to the net is, "Is there a way to have the application see
>}the C/A/D first?"  Any and all help appreciated; TIA...

>Short answer: definitely not in the general case, and probably not at all.

>Even if you do successfully grab C/A/D, there are other ways of killing a
>DV window....

Thanks for the reply.  It does clear up the grubby details.

Incidentally, the point of this was not to stop ugly users from aborting
out - it's not a control issue.  Rather, I have an application (Carbon
Copy to be precise) that cleanly handles C/A/D and it's a shame you
can't use it fully under DV.  In CC, C/A/D very quickly drops your
connection and returns you to DOS: much more quickly than going through
the menus.  But if you are running under DV, the window is closed but
the connection is left active, forcing you to unplug the modem cord.
--

	(Another fine mess brought to you by valley@gsbsun.uchicago.edu)