From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 18-MAR-1993 00:29:13.78
To:	INFO-VAX@kl.sri.com
CC:	
Subj:	Re: Q: Disable CTRL-C in DCL?

	Speaking of Control Y, the trapping thereof, and so forth, my site has
	observed a weirdie.  

	We have a large character-cell terminal application which presents
	overlap- ping rectangular menus using SMG$ (but NOT the SMG$ built-in
	menu cababilities I find those hideous).  We've trapped real ^Y
	keypresses so that they bring up a custom menu of exit options, which
	works fine.  Hit ^Y, you get the Menu.  Hit ^C, you get the menu.  So
	far, so good.  But we recently discovered somewhat by accident, that
	if you press F6, which is "mapped to look like ^Y" by -- which?  the
	Terminal Driver?  or DCL?  I think the former

Correct.  It's deep within the guts of the terminal driver, in fact.  Very
special-case code, completely unconnected with any other code that parses
escape sequences.  (This is necessary because of the timing involved.  In
general, escape sequences are parsed as they are taken OUT of the type-ahead
buffer; doing it earlier won't work because by the time the characters are
read, the program might be doing a binary read.  To act like CTRL/C - NOT
CTRL/Y, BTW - F6 must act immediately, so must be parsed as it is placed
INTO the buffer.)

						      -- you get the INTERRUPT
	message and are back at the DCL prompt.  No muss, no fuss, just no
	trap and no custom menu and no clean exit.  

	My opinion is that this is a bug, but I must admit that I don't know
	exactly how the ^Y-trapping is being performed (someone else "owns"
	that component  at the moment) and therefore what its liabilities
	might be.  Oh, and did I make it clear that this is an application
	written at, and sold by, my company?   Not some third-party software
	we BOUGHT...

	I'd be interested in hearing opinions on this behavior.

Your programmers have fallen into a subtle trap.

There are two ways to trap CTRL/C or CTRL/Y:  Using the old CTRL/C and CTRL/Y
AST's, or using the new OOB (out of band) AST facility.  Both work, but they
are different.  A CTRL/C AST is triggered by a "cancel event", which could be
either a CTRL/C or F6.  An OOB AST for CTRL/C, on the other hand, is triggered
ONLY by an actual CTRL/C character.  The simple proof that this is the
problem:  As I said, F6 sends *Cancel*, NOT *Interrupt* - except that if there
is no active CTRL/C AST enabled, the driver maps *Cancel* to *Interrupt*.
Since you are seeing *Interrupt* when you hit F6, there can be no active
CTRL/C AST.
							-- Jerry