[Allegro] Kopfbefehle

[Bernhard Eversberg]

Zuerst eine Frage an Herrn Thamm:
Von wann ist Ihr  a99.exe? Wenn es älter als 10.2.2012 ist, dann
holen Sie sich zuerst das aktuelle:
   http://ftp.allegro-c.de/aktuelle-version/a99.zip


Zwecks Erhellung der Sache, falls dann noch Unklarheiten bestehen,
muß man weit ausholen:

"Kopfbefehle" deuten mit ihrem Namen schon an, daß sie aus Zettelzeiten
herkommen: Zettel mußte man "köpfen", d.h. mit Überschriften
versehen für die "Nebeneintragungen", um sie dann zwanglos unter diesen
Kopfzeilen in die Schubladen einordnen zu können. (Als man noch die
Zettel mit Schreibmaschine schrieb und per Offsetdrucker kopierte,
mußte man die Kopien dann manuell köpfen.)
Das bedeutete, daß für einen Datensatz i.d.R. mehr als ein Zettel
zu drucken war. So lag die Idee nahe, die erforderlichen Köpfe mittels
"Kopfbefehlen" festzulegen, und die sahen und sehen so aus:

ak=40.+a
ak=41.+b
ak=20+c
ak=31.+d
...

Jeder dieser Befehle lieferte dann - sofern die Felder belegt
waren - einen Zettel; besser gesagt, je einen für jede #40 usw.

In der Anzeige brauchen wir aber stets den Datensatz nur in
einfacher Ausführung, d.h. das Konzept der Kopfbefehle ist hier
ein Fremdkörper.
In PRESTO war es nun aber so gedacht, daß die Anzeigeparameterdatei
eine doppelte Aufgabe hatte: sowohl die Anzeige hervorzubringen als
auch die Zettel zu drucken. Deshalb wurde dann für die Anzeige nur
der erste ausführbare Kopfbefehl tatsächlich ausgeführt. Und wenn
keiner ausführbar war, dann wurde die Kategorieliste von der ersten
Zeile an abgearbeitet. So kam in jedem Fall was raus, wenn nur die
erste Zeile nicht gerade  #+#  lautete.
Dazu mußten in den Parametern noch diese Zeilen stehen:

ad=1   (Aufnahme exportieren auch ohne Kopf, d.h. wenn kein ak-Befehl
         ausführbar ist)
dx=0   Für die Anzeige nicht umcodieren, nur für den Druck

Der zweite war für PRESTO richtig, weil der interne Zeichencode (ASCII)
auch für die DOS-Anzeige galt. für Windows aber geht das nicht,
da *müssen* die Zeichen umcodiert werden (ASCII -> ANSI).
Aus diesem, aber auch aus anderen Gründen (z.B. Flips, Schriftattribute
etc.) konnte unter Windows die Doppelfunktion nicht mehr aufrecht
erhalten werden. Hat man aber eine separate Anzeigeparameterdatei,
die für den Druck nicht herangezogen wird, sind die Kopfbefehle
in ihrer intendierten Bedeutung obsolet. Sie lassen sich ersetzen
durch eine Sequenz dieser Form (da, wo jetzt die ak-Befehle stehen):

#40 +a e0
#41 +b e0
#20 +c e0

#...

Bei den betr. Sprungmarken muß man aber jeweils #u1 durch #40
etc. ersetzen. Denn #u1 wird nur durch einen ak-Befehl belegt.

Das Vorhandensein bestimmter Felder steuert dann den Absprung an
die richtige Stelle der Anzeigegenerierung. Sind alle diese Zeilen
nicht ausführbar, weil die Felder fehlen, geht es an der Stelle #...
los, bei der ersten ausführbaren Zeile also, die demnach auch
nicht gerade #+# lauten darf.

Diese Anordnung ist nicht schwer herzustellen bzw. in einer
existierenden Anzeigeparameterdatei einzurichten, wenn diese noch
mit ak-Befehlen konstruiert ist.
Unsere Standarddatei  d-wrtf.apr  ist schon lange so eingerichtet.

Angst vor dem Experimentieren mit den Anzeigeparametern ist unbegründet.
Es kann dabei an den Daten nichts passieren, denn die Parameter
enthalten keine Speicherbefehle; sie ändern nur das Erscheinungsbild
im Anzeigefenster, nichts am Datenatz selbst.

Wie heißen meine Anzeigeparameter und wo liegen sie?
Das sieht man im admin-Menü:  h adm  eingeben. Mit Klick auf das
Wort "Anzeigeparameter" wird der Editor gestartet, um sie bearbeiten
zu können. Welcher Editor? Derjenige, der mit dem Befehl
Editor=...
in der INI-Datei eingestellt ist. Wenn da
Editor=x
steht, klappt es bei Windows 7/64 nicht. Dann hilft:
Editor=notepad
Besser aber
Editor=winvi
Jedoch muß man sich  winvvi.exe  besorgen und installieren:
   http://www.winvi.de/de/
Denn dieser kann leicht auf MSDOS-Code umgeschaltet werden.
Wer sich mit solchen Dingen unsicher fühlt, wird ohnehin seine
Programm- und Datenordner kopiert haben. Eine vermurkste Parameterdatei
holt man sich dann aus der Kopie zurück.

Gleichwohl und dessenungeachtet werden wir nochmal schauen, ob
wir das "alte Verhalten" noch wiederherstellen, also zurück in
DOS-Zeiten regredieren können.

B.Eversberg