Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!cameron From: cameron@runx.ips.oz (James Cameron) Newsgroups: comp.os.vms Subject: Reading single keystrokes - how do I cope with PF keys? Message-ID: <1501@runx.ips.oz> Date: 4 May 88 02:25:34 GMT Organization: RUNX Un*x Timeshare. Sydney, Australia. Lines: 52 I have a program which allows users to control their local printer queue. It uses the SMG$ Run-Time Library routines for screen control, the $GETQUI system service for obtaining the queue contents, and the $SNDJBC system service for controlling the queue (and jobs). Commands are typed as single keystrokes - S to stop the queue, G to go, etc. There is a VAX MACRO routine that issues the $QIO to read a single character from SYS$INPUT. The $QIO call specifies an AST routine that will handle the character (it does the $SNDJBC according to what was typed). The AST routine requeues the $QIO so as to catch the next character. This is the $QIO used to read the first and next character; $QIO_S chan=channel, func=#io$_readvblk!io$m_noecho, - iosb=iosb, astadr=vq_command_ast, astprm=#buffer, - p1=buffer, p2=#1 ; one character length There's the background - the problem is the PF4 key. It causes the AST routine to be called once for each character of the se- quenceOS, which causes the queue to be stopped, since nei- ther nor O are valid commands. The PF4 key is used in most of our systems as a get-out key. Users are accidently stopping their queues. I've tried adding the function modifier IO$M_ESCAPE to the $QIO, but that simply causes a %SYSTEM-F, Partial Escape status in the IOSB. I've tried enlarging the buffer so that the escape se- quence can fit into it, but that causes the I/O to wait until the buffer is filled before declaring the I/O complete (have to type SSSS or S followed by RETURN). I know I could probably kludge it so that the AST routine would parse the escape sequence - but I'd rather do it some other way. I thought that I could use an unsolicited data mailbox. When the program receives the unsolicited data message, it would issue the $QIO to the terminal with a timeout value of zero, thus catching either a single character that the user typed or the escape se- quence. But I have a worry about that - if the terminal line is low speed, or a multiplexor causes the subsequent characters of an escape sequence to arrive a bit later, will this cause the I/O to only pick up the first few characters of the sequence? Does a read with timeout of zero only read the type-ahead buffer? Or does it wait to see an entire escape sequence if it has noticed an escape character? I would appreciate any comments or help. Please reply by MAIL. I may eventually summarise the response. James Cameron, Kilpatrick Green Pty. Ltd., P.O. Box N366, Sydney 2000 Australia Internet: cameron@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!cameron