a99.exe: vom 11.12.2000 zum 7.6.2001

[Thomas Berger]

Lieber Herr Allers,

Bernhard Eversberg wrote:
> 
> Kollegin Tews hat Recht, ihr Gedaechtnis ist besser als meins. Mir war
> die Sache entfallen, weil sie doch schon laenger zurueck lag!
> >
> > seit V21 muessen die PV-Zeilen geaendert werden, weil #u1 veraendert ist.
> >
> > Wenn ich frueher mit
> > #u1 +B i1,3 i2,2 i3,0 e0     die Kategorie #320 abgeprueft habe,
> >
> > ist es jetzt
> >
> > #u1 +B i6,3 i7,2 i8,0 e0
> >
> Die Aenderung war noetig, damit man in dem Hilfsabschnitt auch
> leicht die Kategorienummer selbst abchecken kann! Das ging vorher
> nicht.

Ich erinnere mich nicht genau, die Angelegenheit ist
aber nicht so einfach zu benennen:

PRESTO hatte sich ueber seine Historie zwei verschiedene
Arten der PV "eingefangen", eine mit leerer #u2 (evtl.
nicht mehr in V20) und eine mit #u2 mit "3" oder "333"
belegt (sowie verschiedene andere Belegungen von #u2).

In der cat.api werden diese beiden Faelle synonym
behandelt, obwohl sie sich sehr stark unterscheiden
(und das Handbuch nicht alles dokumentiert):
Jedenfalls gab es auch hier schon den Unterschied, ob
die Kategorienummer Bestandteil des Arbeitstextes ist
oder nicht (und dann mit #u1 i1,9 i2,0 abgetestet
werden muss) und auch den Unterschied, ob eine im
Hilfsabschnitt produzierte Ausgabe eine Meldung provoziert 
oder die Eingabe ersetzt.

a99 hatte da irgendwelche zusaetzliche Inkonsistenzen,
die im Januar auffielen und loest es seitdem sauberer:
- Kategorienummer ist immer Bestandteil des Arbeitstextes.
- Modifikationen immer mit "M" abschicken
- produzierte Ausgabe ergibt Alertbox

Zu beachten ist dabei, dass der Fall #u2 = 3 in
a99 ueberhaupt nicht mehr existiert, in PRESTO aber
immer noch. Inkonsistent bei a99 war und ist es
moeglicherweise noch (mit v21 nicht getestet), dass 
das "#" Bestandteil des Arbeitstextes sein kann, 
aber nicht sein muss.

Aufpassen muss man, weil der entfallene Modus "3" ja
der "nach Einordnen der Kategorie" war. Will man nun
die aktuelle Eingabe modifizieren, muss man die Kategorie
mit "M" selber belegen *und* dafuer sorgen, dass die
aktuelle Eingabe nicht (nach Ende der PV-Behandlung)
nachtraeglich doch in die Kategorie wandert: 
D.h. es muss eine Ausgabe produziert werden (dies fuehrt
nicht nur zur Anzeige der Alertbox sondern auch zum
Verwerfen der Eingabe durch a99) und diese Ausgabe
muss "-" sein (was dann wiederum zur Unterdrueckung
der Alertbox fuehrt).

Entfallen ist die Moeglichkeit (die ebenfalls im
PRESTO-Modus #u2 = 3 existierte), die produzierte
Ausgabe als Hinweistext in der untersten Zeile
einzublenden: a99 reagiert stets mit Rueckfrage
"Soll das so sein?", wenn man "ja" sagt, wird die
Originaleingabe genommen, wenn man "nein" sagt,
wird die durch die PV modifizierte Eingabe belassen.
Eine Situation also, die man tunlichst vermeiden
sollte...

Neu in a99 sind dafuer die on-Flexe, beispielsweise
der "PV-Flex" onput.flx, der aktiv wird, wenn in der
INI-Datei "SaveAsk=2" gesetzt ist (es war ja manchmal
ein Problem, dass die Programmierte Validierung, die
ja in der .API angesiedelt ist, *immer* aktiv ist,
auch wenn man als Administrator gerade lieber "direkt"
eingeben wollte): Jetzt gibt es also eine .ini- und flex-
Verzeichnis-abhaengige Loesung, die verschiedene Tests
in verschiedenen Situationen ermoeglicht.
PV-Flips 

Wenn das kompliziert erscheint: Vorher war es noch
komplizierter, man ist (mir eigentlich unverstaendlich)
nur nie drueber gestolpert :-)

viele Gruesse
Thomas Berger