[Allegro] a99.zip und index.zip bereitgestellt

[Thomas Berger]

Am 26.11.2015 um 08:14 schrieb Bernhard Eversberg:
> Am 25.11.2015 um 20:06 schrieb Thomas Berger:
>> Am 25.11.2015 um 19:53 schrieb Thomas Berger:
>>> Lieber Herr Eversberg,
>>>
>>> der Fehler war bereits in v35.10 "wieder da", d.h. am 7.10 haben
>>> Sie etwas repariert, das nicht bis zum 22.10. ueberlebt hat,
>>> oder dieses Problem ist einfach nie beseitigt worden.
>>>
>>> Zur Erinnerung:
>>>
>>> x var "otto"\ins $-X#99e\mess
>>>
>>> sollte "otto" zeigen, nicht "-".
>>>
>>> In den order-Flexen gibt es mindestens eine Stelle, wo ein
>>> Wert an zwei Unterfelder zugewiesen wird, da faellt es dann
>>> auf.
>>
> Stimmt. Es gab weit mehr Ärger mit dem anderen, zugleich
> angesprochenen Problem ("Panski-Problem"), da war dies dann in den
> Hintergrund getreten.
> Wird aber noch gerichtet, danke für den Hinweis.

Irgendwo in dem Zusammenhang hatte ich die allgemeinere Frage
gestellt:

Das Problem belegt, dass Zuweisungen von Einzelfeldern derzeit
die PV durchlaufen. War das schon immer so? Ist das ueberhaupt
erwuenscht (die PV-Routinen sehen die Kategorie als ganzes,
also gar nicht das konkrete Unterfeld).

Aber selbst in der allgemeinen Situation eines "ins" eines
kompletten Feldes: Ist PV-Behandlung da angebracht? Die
Funktionen "Warnen" und "Abschmettern" einer Aenderung koennten
mit dem Flex interferieren (seine Aktion sollte m.W. nicht als
/manuelle/ Eingabe aufgefasst werden, immerhin ~koennte~ er
ja den einzutragenden Inhalt selber pruefen), bleibt die
PV-Funktionalitaet des Verschoenens oder Normierens von
Inhalten. Historisch gab es da einige Dinge zu beachten, bei
Feldinhalten laenger als x Zeichen konnte die PV das nicht
direkt bearbeiten, sondern musste es per M-Befehl direkt
im Datensatz ablegen und durch Ausgabe von "-" dafuer sorgen,
dass der folgende PV-Durchlauf (Doppel-Durchlauf noch so eine
PRESTO-bedingte Eigenheit) das nicht wieder zunichte machte.
Je nachdem, wie es implementiert ist, muss man zwar damit
rechnen, dass der eigentlich zu speichernde Wert durch die
PV manipuliert wurde, es ist aber nicht unbedingt so, dass
die Ausgabe der PV diesen Wert enthaelt.

Ein "ins #kkf" muesste mit PV-Beruecksichtigung also so implementiert
werden, dass es anschliessend #kkf *explizit ausliest* und das dort
gefundene in der iV zurueckliefert. Und - da das ausgelesene
ja vom hineingeschriebenen abweichen kann - ist das dann zwar
sauber, aber sehr unintuitiv. Und /ergaenzende/ ins-Befehle wie
ins $x+#kkf waeren fast unmoeglich zu implementieren: Selbst
bei zusaetzlichem Vergleich vorher/nachher koennte die PV diese
Ergaenzung mit dem vorhandenen zusammengefasst haben: Wir haben
dann hinterher noch genauso viele Unterfelder $x wie vorher, aber
eins oder mehrere davon haben sich geaendert: Das konkret ergaenzte
Unterfeld als potentieller iV-Inhalt nach dem "ins" laesst sich
also gar nicht definieren!

Sofern nicht Alt-Anwendungen auf das Wirken der PV im Hintergrund
bauen, moechte ich daher vorschlagen, wieder(?) zu implementieren
und auch in der Dokumentation zu hinterlegen, dass insert-Befehle
/ohne/ PV-Beteiligung ausgefuehrt werden, und freie Eingaben und
Formulareingaben allerdings weiterhin eine PV-Operation ausloesen.

viele Gruesse
Thomas Berger