jdc@naucse.UUCP (John Campbell) (12/03/87)
We're stuck. We are trying to use Digital's Authoring Language (DAL) on VMS and we want to read keypad keystrokes. There is an example in the manual that we can not get to work. All attempts to use the DAL INPUT facility (a terminal read routine) have failed to put escape sequences into the proper string descriptor (RESPONSE). Does anyone out there have a piece of DAL code that uses INPUT or QUERY and can find keypad or cursor key strings? Sorry to turn to the net, but what the heck... John Campbell ...arizona!naucse!jdc Unix? Sure give me a dozen, all different colors.
chuck@felix.UUCP (Charles Vertrees (Chuck)) (12/07/87)
In article <516@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes: >We're stuck. We are trying to use Digital's Authoring Language (DAL) >on VMS and we want to read keypad keystrokes. There is an example >in the manual that we can not get to work. All attempts to use >the DAL INPUT facility (a terminal read routine) have failed to >put escape sequences into the proper string descriptor (RESPONSE). > >Does anyone out there have a piece of DAL code that uses INPUT or >QUERY and can find keypad or cursor key strings? I know nothing about DAL but this sounds like a similar problem I came across once. When VMS went from V3.x to V4.0, DEC added command line editing and recall. If you have a VT100 type terminal then you can use the arrow keys (among others) to use these new features. The problem is that these keys generate escape sequencies. Command recall was implemented in DCL, but the command line editing was implemented in the terminal driver. As a result, the terminal driver now interprets all escape sequences, discarding invalid ones (an error condition is actually returned I believe). The problem arises if you want to grab escape sequences yourself. We had several utilities that used escape as a command attention key. These programs stopped working when we upgraded to V4.0. The only solution we could come up with at the time was to disable command line editing. When this was done, the terminal driver stopped trying to mung the characters and everything went back to normal. Of course command line editing was no longer available in the utility, but a utility that works was better than one that did not. The simple solution was to wrap invocation of the utility in a DCL script which turned command line editing off prior to starting the utility and then re-enabled it upon exit. I believe the commands to do this are $ SET TERMINAL /NOEDIT and $ SET TERMINAL /EDIT. These utilities were written in Pascal, and were performing their own QIO's for input on a character basis. With editing turned on, everything worked fine except we couldn't capture escapes or any following characters until the driver determined it was an invalid escape sequence. Turning off editing provided a quick fix after much more sophisticated experimentation proved futile. There may be some other more elegant solutions available now, but it has been about a year since I was on a VMS machine, and I have not been following it very closely. Hope this helps you solve your problem. Chuck Vertrees.
cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) (12/10/87)
A friend of mine here at BSU has been working on a set of utilities to use with DAL to do everything from key-grabbing to asynchronous-system-trap routines, to ... well, you name it, he's probably gotten it to work despite the limitations of DAL. If possible, I might be able to get him to comment on your posting, and/or cough up some code... I'll see if I can twist his arm ;-) ! Chris