valley@gsbsun.uchicago.edu (Doug Dougherty) (04/20/91)
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)
rreiner@yunexus.YorkU.CA (Richard Reiner) (04/20/91)
valley@gsbsun.uchicago.edu (Doug Dougherty) writes: >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. Recent versions of DV allow additional values, not just 0-4, for the keyboard conflict setting. See your DV manual for details. Perhaps one of the new values does what you need.
valley@gsbsun.uchicago.edu (Doug Dougherty) (04/20/91)
rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >valley@gsbsun.uchicago.edu (Doug Dougherty) writes: >>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. >Recent versions of DV allow additional values, not just 0-4, for the >keyboard conflict setting. See your DV manual for details. Perhaps >one of the new values does what you need. Yes, I've since noticed that. I wrote the orig item from work, using an old version of DV (that only had 0-4). At home, I run a more recent version, that supports 0-F. Though, I'm not sure I want to try all those values (Who's got that kind of time??? [heh] [heh]) Incidentally, the DV manual only talks about the 0-4 set, and even that only incompletely. They describe 0 & 4 and then say 1, 2, & 3 are in between, though not necessarily in a strictly linear ordering... DesqView: Great software, tacky documentation, and piss-poor support. (But I love it anyway...) -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)
ralf+@cs.cmu.edu (Ralf Brown) (04/20/91)
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. Long answer: DV reprograms the interrupt controller so that it gets first dibs on all hardware interrupts, and passes the interrupts along to the original handlers as appropriate. You would have to hook the reprogrammed IRQ vector to have any chance of seeing Ctrl-Alt-Del before DV, but to do so, you first have to find the reprogrammed IRQ.... For DESQview versions through 2.22 (and possibly as high as 2.25), IRQ1 got moved from INT 09h to INT 51h. For DESQview version 2.26 and up (possibly as early as 2.23), it gets moved to the first free block of interrupts in a search list which varies from version to version. If you are running QEMM 5.00 or higher, it is possible to use a VCPI INT 67h call to ask where the IRQs are vectored. Even if you do successfully grab C/A/D, there are other ways of killing a DV window.... -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
valley@gsbsun.uchicago.edu (Doug Dougherty) (04/20/91)
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)
karl@anasaz.UUCP (Karl Dussik) (04/24/91)
In article <1991Apr20.125614.22252@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes: > >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. Here's another suggestion that may do what you want: DV learn mode allows you to attach a sequence of keystrokes to C/A/D. So, just start learn mode, specify C/A/D as the "key" to be programmed, and give it the sequence of keys to exit Carbon Copy through the menus. In my experience, DV programmed keys replay very quickly. If Carbon Copy has reasonable I/O, you may not notice much difference. Good luck. Karl
valley@gsbsun.uchicago.edu (Doug Dougherty) (04/24/91)
karl@anasaz.UUCP (Karl Dussik) writes: >Here's another suggestion that may do what you want: >DV learn mode allows you to attach a sequence of keystrokes to C/A/D. >So, just start learn mode, specify C/A/D as the "key" to be programmed, >and give it the sequence of keys to exit Carbon Copy through the menus. >In my experience, DV programmed keys replay very quickly. If Carbon Copy >has reasonable I/O, you may not notice much difference. No, no, no. Exiting CC through the menus is slow regardless of how the keystrokes are generated. It's just slow. That's all there is to it. That you can exit it quickly via C/A/D is entirely fortuitous. I'm not even sure if it is documented; I just discovered it by accident. -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)