Dadurch, dass ich Code aufgeräumt habe, ist ein neues Problem entstanden.
Ich demonstriere es am besten mit Dummy-Code

Unit 1

markieren

Delphi-Quellcode:

// procedure 1
var // <== NICHT global, sondern in Procedure 1 !
 DataRecord: TDataRecord;
begin
 DataRecord.A := -1;
 DataRecord.B := 2;
 // usw

 DataUnit.ProcA(DataRecord);

Unit 2

markieren

Delphi-Quellcode:

// procedure 2
procedure TDataUnit.ProcA(aDataRecord: TDataRecord);
begin
 if not IsDataOK(aDataRecord) then
  Exit;

 showmessage( aDataRecord.A ); // ist noch immer -1, sollte 0 sein.
 // ansonsten erzeuge hier Klasseninstanz von XYZ anhand der Daten von aDataRecord + schiebe diese Instanz in eine generische TList.
end;

zusammenfalten · markieren

Delphi-Quellcode:

// procedure 3
functionTDataUnit.IsDataOK(var aDataRecord: TDataRecord): Boolean;
begin
 Result := False;

 // überprüfe Daten (strings und integer) aus aDataRecord.
 // Wenn etwas kaputt ist, korrigiere es. Beispiel

 if aDataRecord.A < 0 then
  aDataRecord.A := 0;

 // Bei einer ganz bestimmten Sache wird ggf. Raise ausgelöst (von mir). Dann wird eh abgebrochen.

 Result := True;
end;

Ich dachte, dass ich wegen des Var-Parameters in IsDataOK() in Prozedur 3 nun die korrigierten Daten in Prozedur2 weitergeben kann.

Wo ist mein Fehler?
Ich könnte das Record auch in der Unit-2 selber deklarieren statt in Unit 1 in der Prozedur.
Aber ich weiß nicht ob das Nebenwirkungen hat. Dann wär ich aber die ganzen var-Parameter los.

Zitat von günni0:

markieren

Delphi-Quellcode:

// procedure 2
procedure TDataUnit.ProcA(aDataRecord: TDataRecord);
begin
 if not IsDataOK(DataRecord) then
  Exit;

 showmessage( aDataRecord.A ); // ist noch immer -1, sollte 0 sein.
 // ansonsten erzeuge hier Klasseninstanz von XYZ anhand der Daten von DataRecord + schiebe diese Instanz in eine generische TList.
end;

Ein " if not IsDataOK(aDataRecord) then" sollte es beheben, oder?

Zitat von günni0:

Wo ist mein Fehler?

Schau dir nochmal genau an, auf was du zugreifst.
aDataRecord

Der Parameter aDataRecord ist natürlich eine Kopie.
Du solltest dir dringend überlegen, wieso überhaupt in ProcA auf das "globale?" DataRecord zugergriffen werden kann.

[add]
Und der Name "IsDataOK" ist natürlich komplett falsch, denn da wird nicht "nur" geprüft, sondern auch verändert.

Zitat:

Schau dir nochmal genau an, auf was du zugreifst.

Das war ein Tippfehler hier im Forum.

Im Code steht natürlich ein A davor. Habe es oben korrigiert.

Das DataRecord ist nicht global. Es ist in Procedure 1 deklariert.

Zitat:

Und der Name "IsDataOK" ist natürlich komplett falsch, denn da wird nicht "nur" geprüft, sondern auch verändert.

Dummy-Code!

Hmmm, wenn es wirklich so wie oben ist, dann seh ich keinen weiteren Fehler und es funktioniert somit.
Also nur auf diese Variable bezogen. IF mit Prozedur steht ja nicht zu Frage

Ansonsten wird nur innerhalb von ProcA die Kopie verändert und danach ist es wieder wie vorher.

zusammenfalten · markieren

Delphi-Quellcode:

// procedure 3
function TDataUnit.IsDataOK(var aDataRecord: TDataRecord) : Boolean;
begin
 // überprüfe Daten (strings und integer) aus aDataRecord.
 // Wenn etwas kaputt ist, korrigiere es. Beispiel
 if aDataRecord.A < 0 then
 begin
  aDataRecord.A := 0;
  Result := True;
 end
 else
  Result := False;
end;

Könnte es so funktionieren?

Ich dachte wenn die Daten in IsDataOK() verändert werden, stehen sie mir im Aufrufer (ProcA) zur Verfügung. Aber dort habe ich nur die alten Daten.
Übrigens, noch ein Tippfehler den ich aber nicht im Code habe. isDataok ist natürlich eine Function.

Und nee, ich habe in ProcA trotzdem nur die alten Daten.

Was auch immer ich in IsDataOK ändere, es steht mir in ProcA leider nicht zur Verfügung.

Ach ja, eine globale/zentrale Variable DataRecord anstatt der Übergabe (Parameter/Property) wäre der falsche Weg, für einen sauber Code.


PS: Einfache Struktur-Prüffunktionen baue ich auch gern als Methode in den Record ein, zu dem sie gehören.
Wobei Viele hier natürlich auch lieber zu Daten-Objekten raten würden.

Zitat von günni0:

Ich dachte wenn die Daten in IsDataOK() verändert werden, stehen sie mir im Aufrufer (ProcA) zur Verfügung.

So ist es auch, aber laut dem oben gezeigten verfälschten/pseudogekürzten Code hast du es angeblich richtig gemacht.


@aDataRecord in IsDataOK und in ProcA ansehen ... das sollte ja identisch sein

Ich habe den PC mal neu gestartet... warum nicht.
Jetzt funktioniert es genau wie es soll.

Ich hatte im Laufe des Tages auch bestimmt ein halbes Dutzend mal den Fehler, dass beim Kompilieren Stellen als Fehler markiert wurden, wo gar keine Fehler waren.
Vielleicht ist das ein Bug der durch diesen Bug kommt?