| Hallo,
I have investigated this problem further now and this is the way how we
can reproduce the problem.
Use ALLIN1/KEYB=AZERTY_LK201.
When logged do a RECOMPILE of the form library which contains the Form
DEFAULT from the session logged in on an AZERTY keyboard.
After the recompile use ALL-IN-1 with ALLIN1/KEYB-QWERTY_LK201 on a
qwerty keyboard.
Try now {GOLD Z} and {GOLD W} and you will see that {GOLD Z} display
MESSAGES and {GOLD W} gives the STATUS.
Does somebide have a valid explanation for this behaviour.
Thanks ,
Regards,
Luc Bervoets - DS Belgium
|
| re: <<< Note 2920.1
Hi Luc,
I have highlighted some of your points and will deal with them one at a
time. As far as I can see b. and c. are probably red herrings.
Keyboard mapping is a feature in ALL-IN-1 that only comes into its own
when the language OA$DEFAULT_LANGUAGE is not US type English
At the end of this reply I have enclosed a write up that describes
mapping. It is old (v2.3) but still very relevant. I think most of your
queries will be solved once you have read that. Thanks to Alan McLean &
Christine Landles.
The important observation is that keyboard maps are part of the
European office responsibility (FLC at ECSO Frankfurt) and then the
individual country to provide support for locally supported keyboards.
I hope all this helps. Let us know how you got on.
tta rv 7-Jul-1993 17:32
a>>> Use ALLIN1/KEYB=AZERTY_LK201.
For you to do this successfully requires the file
OA$DATA_SHARE:AZERTY_LK201.A1KMT to exist physically and also to be
present in the dataset OA$KEYBOARDS which is where ALL-IN-1 looks for a
map in the first instance.
b>>> When logged do a RECOMPILE of the form library which contains the
>>> Form DEFAULT from the session logged in on an AZERTY keyboard.
- red herring - I think
c>>> After the recompile use ALL-IN-1 with ALLIN1/KEYB-QWERTY_LK201 on a
>>> qwerty keyboard.
- red herring - I think
- Same other comment as for a.
d>>> Does somebody have a valid explanation for this behavior.
Check the existence AND contents of the files
OA$DATA_SHARE:AZERTY_LK201.A1KMT and
OA$DATA_SHARE:KEYB-QWERTY_LK201.A1KMT to see any 'obvious' explanations
as to why the keys you are pressing appear to have been redefined (they
don't do what you want).
In general a keyboard map can allow you to redefine any sequence to
deliver any other sequence to ALL-IN-1.
For example: You could redefine GOLD F (PF1 F = EXIT) to become
EXIT SCREEN (KP0 = QUIT ) !!!
PC ENVIRONMENT:
===============
If you are running on PC's , there is usually software running in the
PC which ALSO redefines keystrokes; this may also be part of the
problem here.
Here is the write up promised above:
It refers to V2.3 but is still current.
How to Integrate Non-US Keyboards into ALL-IN-1 V2.3
Introduction
In V2.3 it is now possible to fully integrate non-US versions of all the
keyboards supported by this version of ALL-IN-1. It is also possible to
have separate keyboard mapping's for ALL-IN-1 and WPS-PLUS/ALL-IN-1. Each
country is responsible for providing support for their particular
keyboards in their kits. This document will explain what LEGs have to do
to have their keyboards supported within ALL-IN-1.
Selecting a Keyboard - A User Perspective
There are two ways in which a user can specify what type of keyboard he
wants to use in his ALL-IN-1 session :
o Field KEYBOARD on the user profile. In this field a
user will put the name of the keyboard he uses most
often.
o /KEYBOARD = <override_keyboard_name> ALL-IN-1 command
line qualifier. If a user wants to override the
keyboard specified by his profile setting then he can
do so by using this qualifier.
Implementation Overview
1. System-Wide Data File
The name which is given in the KEYBOARD field or as the parameter to the
/KEYBOARD qualifier is a key into a system-wide data file -
OA$DATA_SHARE:OA$KEYBOARDS.DAT This data file contains one record for
each keyboard which is available on the system.
The ENTRY form OA$KEYBOARDS provides the basic interface to
OA$KEYBOARDS.DAT. It has the following structure :
Keyboard Mapping Data
Keyboard Type: <---------------25 ch -------------->
Layout Form : <------ 15 ch -----> Help Form : <----- 15 ch ----->
Keyboard Description : <---------------- 41 ch ------------------>
ALL-IN-1 Map File : <---------------- 32 ch --------------->
WPS-PLUS Map File : <---------------- 32 ch --------------->
where 'ch' = 'characters'
The Keyboard Description field is not used by ALL-IN-1. It is intended
purely to give additional comments on the keyboard.
During the country kit installation a record will be added to
OA$KEYBOARDS.DAT for each new keyboard that the country will support.
Each country is responsible for providing their own version of the
pre-populaion file oa$keyboards.scp. Details of how they add their own
records to this file are included in the file itself.
2. Using a Non-US Keyboard
At ALL-IN-1 startup, the initialisation code will :
o Evaluate which type of keyboard to use during the
session - either from the PROFIL field or from the
/KEYBOARD qualifier.
o Read the appropriate record from OA$KEYBOARDS.DAT and
from this record :
o Load up internal symbols to indicate what the
help frame and keyboard layout forms are
called.
o Load up an internal keyboard mapping table
with information in the ALL-IN-1 keyboard
mapping file provided for this keyboard.
o Load up an internal symbol to indicate what
logicals to create for WPSPLUS keyboard
mappings. Note that, at this time, nothing is
done to set up any keyboard mappings for
WPSPLUS. This will be done, by ALL-IN-1, when
entering the editor for the first time in the
session
ALL-IN-1 now has an in-memory representation of the keyboard mapping
table. When a key sequence has been typed at the keyboard the keyboard
interface code will first lookup the keyboard mapping table (if one
exists) to see if this key has been mapped. If it has then the interface
code will pass to ALL-IN-1 the mapping of the typed key rather than the
typed key itself. In this way keys which are mapped by a keyboard mapping
table will always take precedence over any other key definitions used
within ALL-IN-1 (e.g. form DEFAULT).
+-+ +-----------------+-----------------------+
|K| | KEYBOARD | ALL-IN-1 |
| | | INTERFACE | |
|E| | | | ^ |
| | | | | | |
|Y| | | V | |
| | | +--------+ | +-----+--+ |
|B|<-----+-+KEYBOARD|<-----+-----+COMMAND | |
| | | |MAPPING +------+---->|PARSER | |
|O|------+>|TABLE | | +-----+--+ |
| | | +--------+ | ^ | |
|A| | | | | |
| | | | | | |
|R| | | | V |
| | | | |
|D| | | |
+-+ +-----------------+-----------------------+
Key Mapping Flow
One side effect of this is that UDPs now become completely keyboard
dependent. Any UDPs supplied by the LEGS may need modifying to take this
into account. This will be explained later.
Specifying ALL-IN-1 Mappings
The purpose of the ALL-IN-1 keyboard mapping file is to list all the keys
on the local keyboard which perform different functions to those on a US
LK201 keyboard.
The map file has a very simple syntax. Each line specifies one key map as
follows :
< local key sequence > , < equivalent LK201 key sequence>
The comma is is significant but white space (tabs/spaces/blank lines) are
not. It is also possible to add comments to the file by preceding them
with the "!" character.
An example from the German LK201 map file :
GOLD Y, GOLD Z ! GOLD STATUS
GOLD Z, GOLD Y ! GOLD FUSSNOTE
GOLD �, GOLD # ! GOLD RECHNEN
GOLD �, GOLD ' ! GOLD ERSETZEN
GOLD �, GOLD ; ! GOLD GLOBAL ERSETZEN
GOLD �, GOLD [ ! GOLD KOMMANDO
GOLD �, GOLD - ! GOLD TRENNSTRICH
It is possible to specify a map for every key on the keyboard - even if
it maps to the same key as on the US LK201. This is not advised as it
will make the internal keyboard mapping table unnecessarily large.
UDPs
UDPs will only need changing if they use key sequences which are
different between the local keyboard and the US LK201. If a UDP uses a
key sequence which is the same as on the LK201 then that UDP will not
need changing.
Specifying WPSPLUS Mappings
WPSPLUS uses a different method to map keys. The file KOTERMTAB.COM lists
a variety of keyboard mappings. Each table is represented by a logical
name. Prior to V2.3, a user had to, somehow, define the appropriate
logicals for the type of keyboard he wanted to use.
In ALL-IN-1 V2.3 KOTERMTAB.COM is still used and new mapping tables for
WPSPLUS should still be put there. However, instead of having to define
all the logicals by hand, only the names of the input conversion tables
(KBD_xxx) and output conversion tables (OUTPUT_xxx) logicals need be put
into the WPSPLUS Mapping field of OA$KEYBOARDS by the pre-population
file. The first time WPSPLUS is activated in a session, ALL-IN-1 will
expand these logicals, if appropriate, and create the expanded logicals
automatically.
For example, if the WPSPLUS key mappings are normally set up via the DCL
command
$ DEFINE KOA$TERMINAL_TTC3 OUTPUT_ALTROM, KB_VT100_GERMAN
then the WPSPLUS Mapping field should contain "OUTPUT_ALTROM,
KB_VT100_GERMAN".
|