In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel

Redefining Keys

I don't know if you've ever been faced with the problem of wanting to change the way in which a key operated, perhaps disabling the F10 key entirely to prevent its popping up the Main Menu when your user pressed it accidentally. Or perhaps you've felt that the current range of Macro Keys (Alt-1 through Alt-5) was not large enough and that you wanted to add Alt-6 through Alt-0.

Well, it is possible. All that is required is an understanding of how INPUT.CHAR processes user keystrokes. (INPUT.CHAR is the system subroutine for getting user keystrokes and passing them to application programs. It is also responsible for initiating the background updating of indexes when no key has been pressed for a specified length of time. For documentation on its use see the UTILITY.DOC file on the UTILITY volume of your system). The processing within INPUT.CHAR could be represented by the logic flow

0001    LOOP
0004              BEGIN CASE
0005                   CASE KEY IS IN @PRIORITY.INT
0006                        GOSUB PROCESS.PRIORITY
0007                   CASE KEY IS IN ........................
0008                        GOSUB ........................
0009                   CASE 1
0010                        RETURNABLE KEY PRESSED
0011              END CASE
0012         END ELSE
0014                   CALL INDEX UPDATE PROGRAM
0015              END
0016         END
0017    REPEAT

Note that before any further processing of the keystroke is done, the keystroke is checked to exist in @PRIORITY.INT. This system variable is documented in UTILITY.PROGS on the UTILITY volume but to paraphrase, it contains the low-level keystroke functions, that is, keystrokes which are always present, namely TCL access, Macro Editing and of course the Macro Keys themselves. Thirteen key definitions in all, of which the last five are the Macro Keys.

The layout of @PRIORITY.INT is very straightforward, it simply contains thirteen fields, each one containing the scan code (see Note 1) for the appropriate key. Thus if we look at @PRIORITY.INT<9> we would see that it contains the scan code for Alt-1, @PRIORITY.INT<10> contains the scan code for Alt-2 and so on through to @PRIORITY.INT<13> which contains the scan code for Alt-5. There is another system variable called @MACRO.KEYS which contains the code and command sets for the catalyst calls used by the macro keys. This has two multi-valued fields. Field 1 contains a list of the codes and field 2 contains a list of the commands. Thus the code/command set for Alt-3 would be in @MACRO.KEYS<1,3> AND @MACRO.KEYS<2,3> respectively.

Knowing this is useful in itself as it means that we can dynamically change Macro Key assignments from within our programs, but what is even more useful is the fact that if we append Scan Code values to @PRIORITY.INT, the system will treat them as additional Macro Keys and try to process then accordingly. Thus if we add the scan code for Alt-6 into @PRIORITY.INT<14>, and we put our own code and command set into @MACRO.KEYS<1,6> and @MACRO.KEYS<2,6> we will have added a new Macro Key.

This technique can be extended to allow the redefinition of any system key. To redefine the F10 key, try putting the scan code for F10 into @PRIORITY.INT<14>, the code "HL" into @MACRO.KEYS<1,6> and the command "F10 Key Disabled" into @MACRO.KEYS<2,6>. Now try pressing F10 anywhere in the system and see what happens!

0001      @PRIORITY.INT<14> = CHAR(0) : CHAR(63)
0002      @MACRO.KEYS<1,6> = "HL"
0003      @MACRO.KEYS<2,6> = "F10 Key Disabled"

One caveat to be aware of. A system RESET, or a reloading of a Macro Set will delete your macro definition. This can be problematical, but can be avoided by not giving your user TCL access and preventing them from defining macros. Alternatively, @PRIORITY.INT<7> and <8> are concerned with macro definition, so why not just set them to null from within your program, this will prevent the user from being able to access the macro window. When you no longer need your key redefinition, simply restore then to their former value.


One additional point that you may find useful relates to @CUR.BUF the system variable that contains the current "Cut Buffers" definitions (you know, what is pasted into place when you ^F4). This again has a very straightforward structure, with @CUR.BUF<1> containing the current buffer number, and @CUR.BUF<2>-<6> containing the buffer contents. As @CUR.BUF is just a dynamic array we can alter the contents programmatically and even more impressive, we can add additional buffers beyond the original five. Just add fields onto @CUR.BUF and they will be ready for use as soon as @CUR.BUF<1> is set to point to them. For example set @CUR.BUF<1> to 100 and put your cut information into @CUR.BUF<100>. When the user presses ^F4 the contents of @CUR.BUF<100> will be displayed!

0001      ANS = ""
0002      CALL MSG("Which Buffer","R",ANS,"")
0003      IF ANS > 0 THEN
0004           @CUR.BUF<1> = ANS
0005      END

Use this in conjunction with the points in "Redefining Keys" above to set up a key allowing the user to choose from any one of an infinite amount of buffers for standard paragraphs, headings, addresses et al.

Note 1: Scan Code is the set of ASCII characters returned by the BIOS when a key is pressed.. For normal keys, A, B, C etc. this is just a single ASCII code, but for extended keys such as F1, Alt-O etc. this is two characters, a CHAR(0) to warn the system that an extended key follows, then the CHAR(x) to identify the key.

(Volume 1, Issue 2, Pages 4,9)
Pixel Footer R1 C1 Pixel