[Allegro] Nachladen mit |i3

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Manecke, liebe Liste,

> In der Demo-DB wird mit der Konstruktion:
> 
>    ***** Es koennten noch selbstaendig gespeicherte Baende da sein: *******
>          deshalb wird eine Nachladung ueber Index 9 versucht:
> #00 +#99J e"=" F" " P"+" |92    wenn ja, dann den ersten nachladen
> ...
> #-j
> ...
> #00 +j e"=" e"" P"+" |93     naechsten Band laden, dasselbe nochmal
> 
> eine Auflistung der Bände erzeugt.
> 
> Das geht schief, wenn zwischen der Sprungmarke und dem laden des
> nächsten Bandes noch ein anderer Nachladebefehl für das gleiche Register
> steht:

Bekannt, soweit ich weiss jedoch undokumentiert. Hintergrund ist, dass
fuer solche Nachladekonstruktionen wie |i2, |i3 etc. ein sogenannter
"Iterator" benoetigt wird, der sich die letzte Position merkt. Und diese
Iteratoren gibt es nur global, pro Register 1-11 jeweils einen.


> #-j
> ...
> #xx p"quatsch" |93
> #00 +j e"=" e"" P"+" |93     naechsten Band laden, dasselbe nochmal
> 
> Sobald #xx eine gültige Kategorie und im aktuellen Satz vorhanden ist, wird offensichtlich der Zähler von |i3 um eins hochgezählt. Jedenfalls wird bei einer solchen Konstruktion nur noch jeder zweit Band angezeigt.
> Dabei spielt es keine Rolle, ob 
> #nn P"quatsch" 
> einen gültigen Schlüssel in Index 9 erzeugt oder nicht.

Ob bei "|i3" der Arbeitstext ueberhaupt eine Rolle spielt, ist eine
Frage, der ich noch nie nachgegangen bin.

> Ich hatte angenommen, dass |im nur wirkt, wenn in i ein dem
> Arbeitstext und der Bedeutung von m entsprechender Schlüssel existiert.

Das waere die Variante, dass der Arbeitstext jeweils einen individuellen
Iterator definiert. Sehr interessante Loesung des Problems und ausserdem
eine Antwort auf die obige Frage. Aber leider nicht bei allegro.
640kB sind bekanntlich genug!


> Was das eigentliche Nachladen angeht, stimmt das ja auch. Was aber das
> Zählen der Nachladeversuche angeht, offensichtlich nicht.
> Ist das so, oder habe ich irgendwo einen Denkfehler? Wenn dem so ist,
> ist es also unmöglich, alternative Schlüssel für eine Nachladung mit |i3
> abzufragen?

Seit ca. Version 15 gluecklicherweise nicht mehr: Man kann den aktuellen
Indexeintrag zwischenspeichern und mit ">" und |92 an derselben Stelle
aufsetzen, vorausgesetzt, die Indexeintraege haben nie mehr als einen
Treffer. Unumgaenglich ist das z.B. in der rekursiven Situation, wo
man einen Registerbereich mit Exemplarsaetzen durchlaeuft und pro
gefundenen Satz auf den zugehoerigen Bestellsatz ueber einen Schluessel
im gleichen Register zugreifen muss.

Ihr Fall ist gluecklicherweise einfacher gelagert:


> Hintergrund meiner Frage: 
> Ich verwende für die Bandverknüpfung alternativ die #00 und die Pica-Produktionsnummer, die bei uns in #89P gespeichert ist:
> 
> #00 +#99J e"[=]" F" " P"+" |92     % wenn B"nde vorhanden, ersten nachladen
> #89P +#99J e"[=]" F" " y2 p"ppn" P"+" |92    
> ...
> #-j
> ...
> #89P +j e"[=]" F" " y2 p"ppn" P"+" |93     
> #00 +j e"[=]" F" " P"+" |93     % naechsten Band laden, dasselbe nochmal
> 
> Das geht immer dann schief, wenn #89P vorhanden ist, aber mit #00 verknüpft wurde.

Wenn Sie eine zweite Sprungmarke spendieren, koennen Sie sogar den Fall
abdecken, dass teils ueber #00 und teils ueber #89P verknuepft wurde
(allerdings wird keine sinnvolle Reihenfolge hergestellt, dafuer muesste
man ziemlich tricksen: nach der Anzeige jeden Bandes erst die Zaehlungen
der jeweils naechsten Kandidaten aller Identnummerkandidaten ermitteln
und miteinander vergleichen: Dann geht der Iterator stets kaputt und
man muss mit der oben angedeuteten Methode vorgehen)

Die folgende Skizze ist etwas komplizierter, denn man koennte ja ganz
einfach auch
#00 |92
#-j
#00 +j |93

#89P |92
#-k
#89P +j |93

veranstalten, was nicht sonderlich erhellend ist.


#nr dpk Z
#00 P"|" Apk    % Identnummernkandidaten einsammeln
#89P y2 p"ppn" P"|" Apk
...
#-k       % aeussere Schleife ueber alle Identnummernkandidaten
#upk +j e"|" e"=" F32 P"+" |92
#nr +#99k Z

#-j       % innere Schleife ueber alle Baende zu einem Schluessel
...
#<        % rueckstapeln nicht vergessen
#upk +j e"|" e"=" F32 P"+" |93

#99k      % naechster Identnummernkandidat
#upk +k y0 dpk b"|" F"|" b0 Apk

Alternativ geht es auch mit einer Sprungmarke plus einem Unterprogramm...


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8lgZENVh3bB0lwMRAqntAKC2zUbX1OXFswIirwPVT4mCENtk4wCeNC6f
9U/jYXHR5A3hdFQOf2BR/i8=
=8RO3
-----END PGP SIGNATURE-----