Open topic with navigation
WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
xcall ACCHR(character[, ...])
One or more numeric codes, separated by commas, each representing an ASCII character. Valid codes are 0 through 255. (n)
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 RETURN 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.
.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
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