Login
Register
Ingres.comNavigation
Learn About
Developing With
Ingres Talk
Information
Toolbox
Views
Character Terminals and Ingres
From Ingres Community Wiki
Contents |
Making Character Terminals Behave with Ingres
With example: Red Hat Linux Console
As dedicated hardware terminals have been increasingly replaced by terminal emulators, knowledge about customization of the Ingres character interface has become harder to find. Nevertheless, new users are still often introduced to Ingres through the older, forms-based tools such as ISQL or QBF. This experience can leave a frustrating first impression of scrambled screens and function keys that do not behave as labelled. This article intends to demystify the scrambled screens and make customization of the Ingres forms system understandable and easy. An example of a customized termcap entry is appended below. It defines the termcap entries for the Linux Console (character console, for an xterm-based example see XTerm and FRS). Thanks to Eduardo S. Brito from CA-Brazil for his contribution to our shared knowledge.
"How exactly does a key actually get mapped to an application?"
This question is frequently asked -- the subject can be confusing because of the different files and factors associated in mapping keys to functions.
This article will explain the relationship between each of the files involved and specific entries in them. It will trace the association of a function being invoked from the key on the keyboard to the INGRES Forms Runtime System (FRS) and ultimately the Ingres FRS application which may be Vision, ABF or Ingres Forms embedded in an application written in third generation programming language such as C.
Because there are so many different terminal types, the termcap file delivered with Ingres supports a finite set of terminal files for some of the more popular terminals available. However, many customers would like to either modify the terminal definitions or create new terminal definitions for terminals that are not supported by Ingres. While Ingres Corporation Technical Support does NOT support specific customisations to terminal definition files, we do support the mechanism that allows the customisation, the knowledge about how they work together to provide desired functionality.
Let's discuss the elements involved in key mapping.
Mapping Objects
A variety of capabilities are built-in to the Ingres forms system. These capabilities provide applications with terminal-independent functionality and are collectively referred to as mapping objects. They include such things as FRS commands (forms system commands) , frskeys (forms system keys) and FRS menuitems. These mapping objects enable the user to navigate an application and to view and edit data on a form in a terminal independent way. Because they are actually built into FRS, they are available both in INGRES forms-based subsystems, such as Query-By-Forms (QBF), and in customized forms applications built with ABF or the embedded query languages.
* FRS commands -- refer to any generic function for an application.
Examples include: previousfield, nextfield, rubout, scrollup, etc.
* Frskeys -- is a naming mechanism that allows an application to let the FRS know that it wants to be notified that a particular physical key was pressed. This mechanism was created to allow the FRS (Ingres Forms Runtime System) to recognize varying number of function keys and differing control keys on different operating systems. It allows the application writer to use a consistent key (e.g. frskey4 for look-up operations) whilst the exact key could be different on different terminal types. The mapping files (eg. vt100f.map) map the physical key to the frskey.
Frskey1 is the first frskey referenced in an application; frskey2 is the second frskey referenced in an application, etc.
* Menuitems -- are used to identify menu items displayed on any screen in an FRS application. Menuitem1 refers to the first item in a menu list; menuitem2 refers to the second item in a menu list, etc.
These mapping objects can be equated to either function key identifiers or control key identifiers in the mapping file.
Mapping Function and Control Keys in the Termcap File
Function Keys, Control Codes and Identifiers
Function keys are the physical keys on the keyboard. Control Codes refer to a combination of the control key and some other key. Thus ControlA means you held down the control key and pressed the A key simultaneously.
Function key identifiers (pf1, pf2, etc.) and control key identifiers (controlA, controlE, etc) are specific key words in the Ingres mapping files that associate the FRS (Ingres Runtime Forms System) function with the keyboard keys.
Machine-specific Control Code Sequences
Each key on the physical keyboard (including up and down arrow keys and page-up and page-down keys) produces a specific control code sequence when pressed. These control code sequences differ depending on the terminal being used.
In the termcap file the physical keyboard keys are associated with their actual machine-specific control code sequences. The notation is similar to the notation used in the Ingres mapping files - but with a confusing twist. The notation in the termcap file looks like this: (for function key number one on the vt100 terminal):
k0=\EOP.
The first thing to notice here is that the function key mappings in the termcap file begin at zero not at one. Thus, k0 identifies function key one. The Ingres termcap file maps the identifiers for the function keys (k0, k1, k2, etc) to the control code sequences that are produced by this particular physical keyboard. Thus the notation k0=\EOP indicates that pressing Function Key One on a vt100 terminal will send the control code sequence "\EOP".
It is very important to understand this association between the function key identifiers in the Ingres map files and the function key identifiers in the Ingres termcap file. Their relationship is constant: For example, the function key identifier "pf1" (used in the mapping file) will always be associated with the function key identifier "k0"in the Ingres termcap file entry for your terminal. Function key2 - "k1" in the termcap file - is always "pf2" in the mapping files, and so on.
How Do I Find the Control Code Sent by a Particular Key?
To determine the control code sequences of function keys for your terminal, you should consult the documentation for the terminal hardware from the manufacturer. In most cases, manufacturers will provide an appendix with this type of reference information.
However, if a terminal manual is not readily available, using a feature of your text editor will help to identify control code sequences being sent by specific keys.
For the vi editor on unix systems, follow these simple steps while in vi:
* Go into "input" mode (i) * Press control-v * Press the function key you want to identify
For the edt editor on VMS systems, follow these simple steps while in edt:
* Bring up the edt editor * Press the escape key. * Press the function key that you want to identify
Using these techniques, instead of trying to interpret the control code sequence, these editors will display it on the screen. You can use this information to identify the control code sequences of keys you want to associate with commands
Files The following files are needed for defining terminal functions:
Unix:
$II_SYSTEM/ingres/files/termcap $II_SYSTEM/ingres/files/*.map
VMS:
II_SYSTEM: INGRES.FILES TERMCAP. II_SYSTEM: INGRES.FILES *.MAP
The "*.map" file specification refers to a mapping file that is needed for each type of terminal. Ingres will look at the value of the environment variable TERM_INGRES to identify which termcap entry to consult and which map file to consult. Thus, if TERM_INGRES = vt100f then Ingres will look for a vt100f entry in the Ingres termcap file. The association of the mapping objects to function/control keys is made in the vt100f.map mapping file. There is not necessarily a mapping file for every terminal type. A default mapping file, frs.map, exists for all standard mapping objects. Examples of mapping files names include vt100f.map and sunm.map. The termcap file has entries for terminals known to INGRES. The setting of TERM_INGRES is a pointer to entries in this file. This file is where the control code sequences are equated with the function key capability identifiers (k0, k1, etc.). (Other things such as visual capabilities of the terminal are also defined in this file, but will not be discussed here for the limited scope of this article.)
When modifying mapping files and termcap files, do not modify the files that are shipped with the INGRES installation. Instead, you may set up your own termcap file and mapping file and set up environment variables or logicals to point to your customized files. For details on redirecting the termcap and mapping file specification, see the information in the "Using INGRES through Forms and Menus" manual regarding INGRES_KEYS and II_TERMCAP_FILE.
There are two benefits to using these environment variables/logicals:
* Any changes will not be permanent * You can make changes and easily recover the original files if necessary. * You will not affect any other users while you are editing the files.
The following section will show through example the association of keys, control code sequences, capability identifiers, and function keys for a specific example. The example used here is for a Sun keyboard, but the same relationships between keys, control code sequences, capability identifiers and function keys can be drawn out for any key on any terminal.
This example traces the F7 key for a Sun terminal using the sunm.map file.
Sequence of association:
1. MAPPING FILE (excerpt from the sunm.map file):
/* Help facility */
frskey1 = pf2 (F7)
\ \ \
\ \ \____ Display on the menu line
\ \________ function key identifier
\_____________ the first frskey identifier
2. TERMCAP FILE (excerpt from the sunm entry in the Ingres termcap file):
Mf|sunm|....
....k1=\E 230z: .....
\ \
\ \_______ Control code sequence from the keyboard
\____________ k1 function key capability identifier
(which is the same as pf2)
3. OSQ FILE (excerpt from an .osq file for key definition)
--------
....
....
'Help', key frskey1 =
begin
help_forms (subject = 'Help Information',
file = '/usr/joe/abfdemo/help/help.hlp');
end
....
....
The chart below shows the sequence of events for what happens when a function key is pressed. It uses the example of F7 on Sun keyboard:
| Step 1. | Step 2. | Step 3. | Step 4. | Step 5. | |
| key | control code | command | function | sunm.map | application |
|---|---|---|---|---|---|
| F7 | \E 230z | k1 | pf2 | frskey1 | Help Facility |
- Whenever the F7 key is pressed on the keyboard, the \E 230z escape sequence is produced. (This is specific to the Sun keyboards. Other terminals will produce different escape sequences.)
- The k1 control sequence capability identifier is defined as the \E 230z sequence in the sunm entry in the Ingres termcap file. So this control sequence is recognised as k1. (This specific example is for the sunm entry in the termcap. In other cases the k1 function will be mapped to a different control code sequence.)
- Remember, the k1 control sequence identifier is associated with the pf2 function key identifier.
- The pf2 function key identifier is equated to the Ingres Forms System logical key frskey1. This is how the FRS forms system is able to notify the application that frskey1 was pressed.
- The application executes the code associated with selection of frskey1, in this case the Help Facility.
Termcap File for the Linux Console
Thanks to Eduardo S. Brito from CA-Brazil
# # Customized file from CA-BRAZIL # # Linux Console (Red Hat Linux) # based on vt320f # linux|Linux emulation mode with function keys:\ :kn#12:\ :ky:k0=\E[[A:k1=\E[[B:k2=\E[[C:k3=\E[[D:k4=\E[[E:\ :k5=\E[[F:k6=\E[17~:k7=\E[19~:\ :k8=\E[20~:k9=\E[21~:k10=\E[24~:k11=\E[25~:\ :kd=\E[B:ke=\E[?1l\E>:kl=\E[D:kr=\E[C:ku=\E[A:\ :mf=bull12.map:tc=vt320f:
