[Allegro] Exportdatei

[Thomas Berger]

Lieber Herr Eversberg,


>>> Wäre es nicht möglich, dass "open x" den Pfad der aktuellen Exportdatei auf
>>> einen Stack schreibt und "close x" ihn dann wieder herauspoppt?
>>> Das würde verschachtelte Flexe (wenn so etwas denn überhaupt wünschenswert
>>> ist) in dieser Hinsicht erleichtern, zumal etliche Flexe ja gar keinen
>>> erkennbaren Export erzeugen, wohl aber die Exportdatei verbiegen.
>>
>> "Normal" in Programmiersprachen ist eigentlich, dass ein "open" [x] implizit
>> ein close des vorigen bedeutet (wenn es denn zum gleichen Handle erfolgt).
> So ist es und so macht's das Programm.
> 
>> D.h. es duerte unzaehlige Alt-Flexe geben, die hier den Stack zum Ueberlaufen
>> bringen koennten.
>>
> Das ist nicht der Fall. (Sonst nennen Sie zumindest mal einen solchen.)

Es ging um den Vorschlag von Herrn Fischer, bei jedem "open x" auf
einem Stack den vorigen Wert mitzufuehren: Wenn es da /implizite/
close's (anlaesslich neuer open's) gibt, wird der Stack naturgemaess
nicht bereinigt und waechst. Oder er wird implizit bereinigt und
hat dann stets die Tiefe 1: Vermutlich hilft das dann Herrn Fischer
nicht weiter ;-)


>>>>> Alternativ könnte bei solchen Flexen die interne Sondervariable gesichert
>>>>> und wiederhergestellt werden, da will ich mir allerdings nicht gerne eine
>>>>> Sammlung  von Privatflexen anlegen.
>>>>> Konzeptionell käme es mir korrekt vor, wenn allgemeine Flexe so gebaut
>>>>> würden, dass sie keinen Einfluss auf interne Einstellungen haben.
>>>>
>>>> Sehr viele Standardflexe retten und restituieren akribisch die Werte
>>>> von Ausgabedatei und Ausgabeparametern. Das ist allerdings nie optimal,
>>>> da das Neu-Laden der Ausgabeparameter etwas im Unklaren laesst, was
>>>> mit Kopf- und Fussteile etc. passiert: Die werden beim ersten/letzten
>>>> Export mittels der Parameter erzeugt, und diese Information ist
>>>> unbekannt...
>>>
> Also was bleibt nun als definitives Desiderat übrig? Ich schau da,
> trotz aller Handlungsbereitschaft, nicht mehr ganz durch.

Ich habe mir nicht die Muehe gemacht, in den Quellen nachzusehen,
wie es tatsaechlich implementiert ist. Aber phaenomenologisch
verhalten sich "open x" und "close x" definitiv nicht 100%ig
wie "normale" open's und close's, die man aus anderen Zusammenhaengen
kennt. Hingegen laesst sich das Beobachtete perfekt durch die Operationen
"Dateiname fuer zukuenftige Exporte ist ..." bzw. "Dateiname fuer zukuenftige
Exporte ist der Defaultwert aus der .ini" erklaeren.

Das ist halt so, ohne dass ich da einen Handlungsbedarf sehe.

Herrn Fischers Ursprungsproblem war folgendes: Nach Ausfuehrung von
ald-erg.flx war die eingestellte Ausgabedatei nicht mehr die
erwartete (ald-erg oeffnet selber eine Ausgabedatei, schliesst die
dann auch, also ist anschliessend das Default aus der .ini eingestellt,
nicht das, was der Anwender zuletzt eingestellt hat und fuer das
moeglicherweise noch die Exportparameter vorbereitet sind).

Das ist mehr als unschoen (der Anwender hat etwas eingestellt, das
darf unter keinen Umstaenden vom "Sytem" spater irgendwie beilaeufig
vergessen werden) und vordergruendig ist die Reparatur, in den erg-*.flx
wie in vielen anderen Flexen auch das "uebliche" Wegretten der
Einstellungen fuer Exportparameter und -Datei in Variablen nebst
abschliessender Restitution einzubauen.

Das ist nicht perfekt, weil es keinen Mechanismus gibt, mehrere Flexe
als Ensemble auszufuehren, so dass diese eine gemeinsame Ausgabedatei
nutzen /und/ hinterher die Ausgangslage restituieren koennen. Und es
ist nicht perfekt, weil - wie am Rande diskutiert - Ausgabeparameter,
Ausgabedatei und der interne Zustand der Ausgabe (ist schon etwas
passiert, was ist mit Kopf- und Fussteilen etc.) eine Einheit bilden,
die nicht als solche gesichert und wiederhergestellt werden koennen:
Ansatzweise ist das moeglicherweise mit dem fuer acon eingefuehrten
und mittlerweile auch in a99 vorhandenen "zweiten" Download-Objekt
realisiert, das waere zu pruefen...

viele Gruesse
Thomas Berger