[Allegro] V32.4 und Indexparameteraufruf

[Bernhard Eversberg]

Am 18.05.2012 10:55, schrieb Thomas Berger:
>
> xset.rtf dokumentiert dieses ungute Verhalten, ...
Welches Verhalten, an welcher Stelle?

> ausserdem stolpere ich ueber "... in avanti ebenfalls automatisch": Gibt es noch
> einen Fall automatischer Sperre (abgesehen von PRESTO)?
>
Nein. Wenn wir die angekündigte Variable dazu noch haben, dann als
default nirgends.

> Die numerischen Fehlercodes / Werte des CString sL finde
> ich im Prinzip ganz brauchbar, wenn sie bei jedem Lesen
> eines Datensatzes aufgefrischt werden,
Das werden sie

> allerdings verstehe
> ich das Muster von Werten und Vorzeichen ueberhaupt nicht,
> eigentlich wuerde man ja "Flags" im Sinne von gesetzten
> Bits erwarten und u.U. differenzieren negative Werte
> verschiedene Abstufungen von "ok" und positive Werte stets
> einen Fehler / Ausnahmebedingung.
Ja, aber nicht alles geht gut zu machen. Der Hinweis auf "gesetzte
Bits" war zu antizipieren, hätte aber in diesem Fall keinen großen
Nährwert. Immerhin kann man mit
if "-"
den Fehlerfall ganz leicht pauschal abtesten, zu einer Marke springen
und dort näher untersuchen.

>
> 0 - ist stets "o.k."
>
Ist das eine Forderung oder ein Statement?

>
> Fehler:
> diverse TBL-Fehler (oeffnen, nicht vhd. Satznummer, Schreibschutz)
> diverse ALD-Fehler (oeffnen, keine Daten, Schreibschutz)
> Inkonsistenz (falsche Satznr. am Satzbeginn in .ald-Datei)
> Satz geloescht / Satznr. nicht belegt
> Regulaeres Problem beim internen .tbl-Lock: Db bereits gesperrt
> Fatales Problem beim internen .tbl-Unlock: Db bereits freigegeben
> Regulaeres Problem bei Lock: Satz ist bereits gesperrt
> Fatales Problem bei Unlock: Satz war nicht gesperrt
>
Eine gute Zusammenfassung eines Maximalkonzepts, aber
muß das *alles* wirklich in diesem Zusammenhang berücksichtigt werden?
Aber OK, wir könnten das Release ja noch bis März 2013 aufschieben, da
wären wir in guter Gesellschaft.

B.E.