[Allegro] a99/alcarta jetzt ANSI-faehig

[Bernhard Eversberg]

Oberflächen-Umcodierungen in a99/alcarta
----------------------------------------
Jetzt voll ANSI-fähig                                   2005-12-20

Das Wichtigste zuerst: Normalanwender brauchen nichts zu tun!
Aber auch WENN sie sich die neuen Programme a99/alcarta holen,
fallen keine Änderungen an irgendwelchen Dateien an.

Wer jedoch mit ANSI oder sonstigem internen Code arbeiten will,
nicht mehr mit DOS-ASCII, der muß sich die neuen Programme holen.
Ganz unten steht, was zu tun ist - denkbar wenig!

Der Bedarf für internes Arbeiten mit ANSI statt ASCII manifestiert
sich. Das neue Neutralmodell soll z.B. mit ANSI arbeiten können!
Im Zentrallabor, wo das Kernsystem betreut wird, wurde deshalb
eine Checkliste aufgestellt und abgearbeitet. Im Ergebnis haben wir
nun durchgängig korrekt arbeitende Programme, sofern nur
minimale Voraussetzungen gegeben sind (siehe am Ende dieses Beitrags).

Es folgt die Checkliste:

Die sichtbaren Elemente sind ausnahmslos auf ANSI angewiesen, vom
Anzeigefeld bis zur kleinsten MessageBox.
Es sind also Tabellen nötig, die zwischen dem tatsäch-
lichen Code der involvierten Daten und ANSI in beiden Richtungen
codieren (manchmal nur in einer, z.B. MessageBoxen, Menüs,
Button-Aufschriften). Diese Aufgaben werden hier aufgelistet
und präzisiert.

Die mit (x) gezeichneten Bereiche sind geprüft und abgehakt, d.h. die
nötigen Änderungen in den Programmen sind gemacht und getestet.

Abkürzungen:
   AS  = ASCII mit OstWest-Zeichensatz,
   AN  = ANSI mit OstWest-Zeichensatz
   INT = intern verwendeter Code, falls beides nicht zutrifft,
         D.h. Intern kann ein von ANSI und ASCII abweichender Code
         verwendet werden, es muß nicht  INT=AN  sein.

Eine "ASCII-Datei" ist eine im ASCII-Code geschriebene. Fast alle
Standard-Textdateien sind ASCII! Ausnahme: UIFE... ist ANSI (das ist
aus internen Gründen nicht zu ändern).


Rezept für die o-Befehle (s.a. am Ende):
A) Index-Parameter : Abbildung zwischen INT und AN
B) Anzeigeparameter: Abbildung zwischen AS und AN


1. Anzeigefeld: (x)
    a) Anzeigeparameter brauchen p/q-Befehle für  INT -> AN
       Damit funktionieren dann auch Flips mit Umlauten!

    b) ASCII-Datei  zeigen       AS -> AN
                    speichern    AN -> AS
       Kategorie-Hilfetexte (Hnnn) fallen auch hierunter, obwohl
       sie in einer MessageBox erscheinen.

2. Auswahlfeld: (x)
    Daten anzeigen           INT -> AN
       Datenfelder
       Reserve
       CFG-Felder     (d.h. auch CFG muß weiterhin ASCII sein!)
       Abfrageliste

3. Eingabefeld (Schreibfeld),  (x)
    Befehlszeile  (x)
    Formulare (x)
    Was man eingibt, ist immer ANSI, was hier angezeigt werden soll,
    ist im internen Code (Kategorieinhalte)! Also:
                          INT -> AN
                           AN -> INT

4. Indexfenster (x)
       In den Registereinträgen selbst sollten möglichst
       keine Sonderzeichen vorkommen, schon wegen der Ordnung.
       WENN es aber der Fall ist, sieht es so aus:
       Registerdaten      INT -> AN
       Eingabe             AN -> INT
       Überschriften in den Parametern: müssen INT sein.

5. ViewListe (x)
       Achtung: Text der Standardlisten ist ASCII, etwas anderes
       geht deshalb zur Zeit nicht. (wie z.B.  FLEX.VW und QUICK.VW)
       Darauf ist beim Erzeugen eigener ViewListen zu achten.

         Anzeige  :        AS -> AN
         Suchfrage:        AN -> AS

6. Ergebnisliste, Text stammt aus STL-Datei (x)
       Text der STL-Zeilen ist INT
                          INT -> AN
         Suchfrage         AN -> INT

7. aresqa-Liste (x)
       Dieses Fenster kann ANSI und ASCII anzeigen!
       (siehe doku:  h xaresqa )
       Wenn Datei ASCII ist, konvertiert es nach ANSI
             Eingabe dann  AN -> AS
       sonst keine Konvertierung!

8. Fernglas-Formular (x)
       Was man hier eingibt, ist ANSI, gebraucht wird INT
                          INT -> AN
                           AN -> INT

9. CFG, Abfrageliste und Formulardatei sind sinnvollerweise INT ! (x)
                  also    INT -> AN
                           AN -> INT

10. FLEXe (x)
     Wenn im FLEX ein Befehl  var "..."  auftritt, und was zwischen
     "..." steht in ASCII codiert ist, dann muß man, bevor ein
     message-Befehl kommt, noch "ansi" sagen. Diese Umcodierung muß
     also gemäß der Abbildung  AS <-> AN  erfolgen.


Was ist zu tun, wenn man intern nicht mit ASCII arbeiten will?

A) Damit die Fälle  INT <-> AN funktionieren, muß es o-Befehle
geben, die den tatsächlich verwendeten Code nach ANSI abbilden.
Wenn intern mit ANSI gearbeitet wird, gibt es keine o-Befehle!
Diese Befehle gehören in die Indexparameter.
Empfehlung: o-Befehle für  INT <-> AN  in eine Datei o.xpt
Dann in die eigenen INDEX-Parameter diesen Befehl:
to

B) Damit die Fälle AS <-> AN funktionieren, muß es eine o-Datei
geben, die der originalen o.apt entspricht. Diese ist in die Anzeige-
parameter einzubinden - dort werden o-Befehle ansonsten nicht
gebraucht, sind also nebenwirkungsfrei.
Empfehlung:  Kopie machen mit dem Namen oasci.xpt  (x = eigene CFG)
Dann in die eigenen ANZEIGEparameter einbauen:
toasci

Ebenfalls leicht zu merken: alle CFG-, Parameter- und Hilfetexte (Hnnn)
müssen ASCII sein, auch ViewListen. Zum Bearbeiten nimmt man WinVi
(der kann umschalten) oder edit (falls man X verschmäht).