[Allegro] Unerwartete Ergebnisse bei viewform.flx

[Bernhard Eversberg]

Sibylle Koczian schrieb:
> 
> Jetzt geht's durcheinander. Das Zusammensetzen von Vorspann, variablem 
> Teil und Nachspann in viewform.flx geht doch mit "write F", an dieser 
> Stelle sehe ich keine Erwähnung von srch.
> 
Auch wieder wahr. Die Datei hinter F wird auf DbDir und dann auf ProgDir
gesucht, auf WorkDir aber nicht (es sei denn, dieses ist =DbDir), und so
macht es auch der t-Befehl in den Parametern.
Testen können Sie das so:
x var Fdateiname\sho IV
Die Datei erscheint dann in der Anzeige - oder eben nicht.
ABER:
In ViewForm.flx wird vor den Dateinamen view1.apt ein P gesetzt,
und also wird NUR im ProgDir gesucht.

>> Das wird gesteuert, indem in #uVy ein j steht. Das kommt aus dem
>> Formular [ViP...] in view2.frm, d.h. man muß es dort eingeben.
>> Bei der Methode "Mit Parametern" steht in viewpara, der Vorlage für
>> die Parameterdatei, daß man einen : zwischen das erste und zweite
>> Feld setzen soll.
> 
> Schließe ich daraus richtig: wenn und nur wenn in der fertigen 
> Parameterdatei zwischen die beiden ersten Felder der Trenner ":" gesetzt 
> wird, ist Gruppierung gewünscht und nur dann darf viewform.flx oder 
> view0.flx eine Batchdatei mit einem srch-Befehl erzeugen?
> 
Nein, das j für die Gruppierung löst aus, daß in den v-Parametern noch
eine Zeile ergänzt wird, die hernach das entsprechende Sortieren und
Gruppieren ermöglicht.
Ferner wird der Sortierbefehl abhängig vom j anders ausgeführt, und es
wird noch ein srch-Export mit viewgrup.apr ausgeführt (unter :grupp in
viewform.flx)

> 
> Letzteres mal auf jeden Fall, wegen 64bit (_deshalb_ doch der Hinweis 
> von H. Berger). Aber innerhalb eines Flexes würde man doch wohl nicht 
> acon aufrufen, sondern den entsprechenden Job gleich in den Flex 
> einbauen, oder nicht?
Das würde eine größere Umschreibung des FLEXes bedeuten. So wie er ist,
fabriziert er einen srch-Aufruf für die Gruppierung. Das hätte dann ein
acon-Aufruf zu werden.

> Und was die Variablennamen betrifft: Von Onkel Bill kann man lernen, 
> dass extreme Kürze nicht notwendig ist, um Sachen sehr schwer 
> begreiflich zu machen. Deshalb bleibt sie aber hinreichend.
Hinreichend zum Erschweren des Verständnisses, meinen Sie. Gut gesagt.
Idealerweise soll aber ein gut entwickeltes Skript am Ende so robust
sein, daß es keiner mehr lesen muß außer dem Programm, und für dieses
ist Kürze allemal hinreichend zum Funktionieren.

> Und ich 
> meine eigentlich, dass die Standardparameter und -flexe doch auch zum 
> Lernen und zum stückchenweisen Übernehmen da sein sollten - oder nicht?
> 
Ja, deswegen stehen ja auch viele Kommentare drin, und in den längeren
FLEXen unten am Ende eine kommentierte Liste der Variablen. Diese
kann man sich jederzeit auch herstellen mit dem FLEX  uvar.flx.
Er liefert eine noch unkommentierte Liste mit Angabe der Häufigkeit,
und die kann man danach mit Kommentaren anreichern. Wir sollten das
für die View-FLEXe mal machen...

Java-Programmierer scheinen mir oft zu glauben, lange Variablen- und
Funktionsnamen sprächen hinreichend für sich, daß man auf Kommentare
ganz verzichten kann, was sie dann auch tun.

B.E.