Externe Datenstruktur basierend auf Bildschirmformat

[Fuerchau]

Nun ja, keine mir bekannte Sprache beherrscht die Syntax "Bool is true", es heißt immer "Bool = true" bzw. "Bool == true".
Wobei man hier z.B. in Microsoft C++ noch unterscheiden muss:
true = 1
TRUE = 1
VARIANT_TRUE = -1 <= Dies ist bei COM-Schnittstellen wichtig.

Einzig die VB-Abfrage "if bool then" liefert immer die korrekte Antwort, "if bool = True then" liefert nur bei "-1" die korrekte Antwort.
Da kann ich mit den Unschönheiten von *OFF/*ON schon leben.

Noch eine Inkonsistenz:
"MOVEA '1111' *IN,1" setzt die IN01-IN04 auf *ON.
"%subarr(*in:1:4) = *ON;" macht das ebenso.
Allerdings ist "%subarr(*in:1:4) = '1111';" nicht erlaubt, da der Compiler nun die Zeichenkette als CHAR abweist.

[hel400]

Ich muss da jetzt aus Neugierde doch nachfragen:

Was ist der eigentliche GRUND, dass die Bildschirmfelder verglichen werden sollen?
Wenn das nur den Sinn hat um zu erkennen, dass vom User in einem Feld Daten erfasst/geändert wurden, geht das ja auch ohne jeglichen Datenstrukturen etc..

[Fuerchau]

Nun ja, so ganz geht das leider nicht.
Die DSPF-Möglichkeiten sind da doch eher eingeschränkt.
Das MDT-Flag (CHANGE, BLANK) teilt mir nur mit, dass in dem Feld was eingegeben wurde.
Wenn es aber der vorherige Wert war wird die BZ trotzdem gesetzt.
Mit Qualified habe ich da halt einfacher die Möglichkeit mir in einer 2. DS die vorherigen Eingaben zu merken. Früher musste ich Hilfsfelder oder DS definieren und jedes Feld einzeln übertragen.

[hel400]

Genau wegen dem CHANGE Schlüsselwort habe ich nachgefragt.
Dass bei Eingabe der "gleichen" Daten die BZ auch eingeschaltet wird, ist klar - das reicht in den allermeisten Fällen ja auch.

Na passt - wollte nur erfragen, ob es da noch weitere Hintergründe gibt.