Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!midway!gsbsun!valley
From: valley@gsbsun.uchicago.edu (Doug Dougherty)
Newsgroups: comp.os.msdos.apps
Subject: Desqview and Ctrl/Alt/Del
Summary: Applications which handle c/a/d running under DesqView.  Does it work?
Keywords: desqview ctrl/alt/del trapping programming
Message-ID: <1991Apr19.174531.15849@midway.uchicago.edu>
Date: 19 Apr 91 17:45:31 GMT
Sender: news@midway.uchicago.edu (NewsMistress)
Organization: University of Chicago
Lines: 20

Some time ago, I got into a flame war with some people about whether or
not it was a good idea for applications to try to trap/disable/handle
the control/alt/delete keyboard combination.  I think it is a bad idea
in general, but the net result/answer to the question is probably a very
qualified "Yes, but only if your program is indeed 'camera ready', i.e.,
a fully debugged consumer product."

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."

I have tried every value (0-4) of the "Keyboard Conflict" variable in
the .DVP file, in conjunction with a "NOBOOT" TSR, but in every case, DV
closes the window when C/A/D is struck.

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...
--

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