[Allegro] Geisterhände in a99?

[Bernhard Eversberg]

Mentzel-Reuters schrieb:
> Nach neuerlichen Abstürzen habe ich mich heute dazu durchgerungen, die 
> FF mit einem HexEditor zu beseitigen und dann eine komplette Erneuerung 
> zu machen, wie Herr Eversberg es vorgeschlagen hat. Das ging alles 
> problemlos. Natürlich sind wir jetzt mit dem Copy&Paste vorsichtiger, 
> größere Blöcke gebe ich erst einmal nach Notepad, das das FF rauswerfen 
> dürfte, und kopiere sie dann erneut. Generell läßt sich wohl keine 
> Abhilfe schaffen (z.B. daß die Presto-eingabe kein FF akzeptiert)? 
PRESTO akzeptierte noch nie einen Code 255 innerhalb eines Feldes! Denn 
dieser Code wird als Feldende betrachtet und beim Speichern durch 0 
ersetzt, was auf dem Bildschirm dahinter steht, ignoriert. Der Code
255 auf dem Bildschirm ist nicht von einem Spatium unterscheidbar,
d.h. man sieht ihn nicht. PRESTO braucht ihn, um das Feldende zu
erkennen, wenn z.B. mit [Ende] der Cursor dorthin springen soll.

Nur durch IMPORT kann eine 255 in die Daten geraten.
Das können Sie verhindern durch

y .255 256

in den Importparametern.
Wenn Sie allerdings eine .ALG-Datei selber machen (mit Perl oder so)
und dabei die 255 als Datenzeichen zulassen, und diese dann mit
UPDATE einmischen, bleibt die 255 drin.

 > Und wie ist es eigentlich bei Copy&Paste in a99?

In der o.apt steht

o .152 255   y mit trema

d.h. beim Eingeben wird die 255 in 152 gewandelt und demnach so
gespeichert.

Eine Zeile mit

o .255 ...

gibt es aber nicht, wenn demnach in den Daten schon eine drin ist
(durch UPDATE reingekommen) dann sehen Sie links das Zeichen y mit
Trema, rechts mit F5 scheint es, als sei an der Stelle ein
Zeilenvorschub, und das hat seine Richtigkeit, denn wenn Sie in den
Exportparametern mit
p ... 255
eine 255 zuweisen, wird diese nicht als solche, sondern als
Zeilenvorschub rauskommen, das steht so auch im Handbuch.

Wenn man solche Daten indexiert (eben getestet), bleibt die 255 drin,
bei "Index erneuern" sowieso, bei "ganz neu aufbauen" aber auch.

Bei Copy&Paste aus dem DOS-Fenster heraus macht Windows (nicht allegro)
aus der 255 die 160. Die stört dann natürlich, ist aber ungefährlich.
Sie landet via o.apt als Code 15 in der Datenbank.


B.E.