Define additional activation characters
|
WSupported on Windows
|
USupported on Unix
|
VSupported on OpenVMS
|
NSupported in Synergy .NET
|
xcall ACCHR(character[, ...])
Arguments
character
One or more numeric codes, separated by commas, each representing an ASCII character. Valid codes are 0 through 255. (n)
Discussion
The subroutine ACCHR defines additional characters to be processed as activation characters during terminal input. (You can later deactivate the specified characters using the DACHR subroutine.)
Activation characters are only meaningful with terminal READS, the W_FLDS(WF_INPUT) subroutine, and the W_DISP(WD_READS) subroutine. In all other situations, and when used with a non-interactive runtime on Windows, activation characters are ignored. If no activation characters are defined, terminal input ends when a standard record terminator is encountered. The standard terminators for terminal input are the carriage return, line feed, form feed, Tab, and Esc keys. Standard terminators cannot be undefined.
When you define activation characters using ACCHR, Synergy DBL considers the specified characters to be terminal input terminators. The input operation ends when either a standard terminator or an activation character is encountered. The receiving data area does not contain the terminating character. The terminating character is always accessible from either the %RDTRM (or %RTERM) intrinsic function or the RSTAT external subroutine.
Activation characters are not echoed, which means that your program can stop input from a CRT screen without corrupting information displayed on the screen. Input from the last line of a CRT screen does not scroll the screen if the input terminator is an activation character.
When the user presses Enter in response to a terminal input request, the system automatically generates a record terminator (a carriage return/line feed pair on Windows and OpenVMS and a line feed on Unix). Both characters are echoed to the terminal, and the line feed, as a standard record terminator, ends the input action. The %RDTRM (or %RTERM) intrinsic function or the RSTAT external subroutine indicates that the line feed was the terminating character.
However, if the program defines the carriage return as an activation character, a different set of actions occurs. The system doesn’t echo or internally generate a line feed in response to a carriage return. The carriage return ends the input request, and the %RDTRM (or %RTERM) intrinsic function or the RSTAT external subroutine indicates that the carriage return was the terminating character.
If the delete character is set as an activation character, it is ignored as an activation character in W_FLDS(WF_INPUT).
If you try to define an activation character that is already defined, your attempt is ignored, and the character remains defined. Activation characters are reset by STOP chains.
|
If you use UI Toolkit, all details of managing function key processing are handled for you. |
See also
DACHR routine
Examples
.define TTCHN ,1
record
io ,a30
i ,d3
proc
open(TTCHN, i, "tt:")
xcall acchr(7, 9, 13, 127) ;bell, horizontal tab, carriage return, rubout
loop,
display(TTCHN, "Type the input: ")
reads(TTCHN, io) [EOF=DONE]
display(TTCHN, '... Input was "')
if (%rdlen)
display(TTCHN, io(1, %rdlen))
io(1,3) = %rdlen [left:i]
io(11,13) = %rdtrm, "XXX"
write(TTCHN, '" (' + io(1,i) + ") long, terminated" +
& " by code ", io(11,13))
goto loop
done,
stop
end
Special notes
Many CRT terminals have function keys that transmit character sequences to the computer. Because they often begin with the ASCII escape character (ESC), we refer to them as escape sequences. Your terminal user guide describes the special functions and sequences available.
In the past, programs that used these special function keys assumed the entire burden of terminal input management. They had to turn echoing on and off, receive each character using the ACCEPT statement (thus incurring the overhead of single-character input), and perform all activity on the characters received (character echoing, character/line deletions, field overflow control, deleted character repainting, and so forth). This extra coding often limited a program to a specific environment, which restricted portability.
Synergy DBL simplifies the writing of compact routines to handle intricate terminal input requirements, because the runtime performs most of the required functions internally. The runtime provides functionally identical features regardless of the operating environment, which enables you to move your programs easily between operating systems.
The following example illustrates the use of the ACCHR subroutine for terminal input. Several utility functions are enabled upon input of either control characters, or VTn00 function keys. This example also illustrates the use of TTFLGS 4, which causes the Synergy runtime to parse escape sequences and return a code based upon the key.
main test_fkeys
record
function ,i4
inp_string ,a80
.define FUNCTION_1 ,1
.define FUNCTION_2 ,2
.define FUNCTION_3 ,3
.define FUNCTION_4 ,4
.define FUNCTION_5 ,5
.define FUNCTION_6 ,6
.define FUNCTION_7 ,7
proc
open(1, o, "tt:")
xcall ttflgs(4000, 1) ;Enable parsing escape sequences
; (Unix and OpenVMS) so we DON’T
; have to activate 27 below
xcall acchr(1,2,4,5,6,8,10) ;Activate CTRL+A,B,D,E,F,H,J
reads(1, inp_string)
using %rdtrm select
(1, 294), ;CTRL+A or F14
function = FUNCTION_1
(2, 274), ;CTRL+B or Up Arrow
function = FUNCTION_2
(4, 276), ;CTRL+D or Left Arrow
function = FUNCTION_3
(5), ;CTRL+E
function = FUNCTION_4
(6, 277), ;CTRL+F or Right Arrow
function = FUNCTION_5
(8, 292), ;CTRL+H or F12
function = FUNCTION_6
(10, 293), ;CTRL+J or F13
function = FUNCTION_7
(), ;Undefined
clear function
endusing
writes(1, "Function " + %string(function) + " activated")
endmain
