Konnte den Fehler weiter eingrenzen. In meiner Anwendung gibt es 14 Richedit-Objekte. Um sie allgemein ansprechen zu können definiere ich eine globale Variable
Delphi-Quelltext
1:
| var Re : Array[1..14] of TRichedit |
Unter Form1.Create weise ich zu
Delphi-Quelltext
1:
2:
3:
4:
| Re[1] := Richedit1;
Re[2] := Richedit2:
..
Re[14]:= Richedit14; |
Im Programmcode steht dann z.B.
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
| with Re[vAktulleRe] do
begin
LinesBeginUpdate; Modified := false; ...
LinesEndupdate
end |
Die Frage ist, warum der Quellcode mit Delphi32-Compiler alles bestens funktioniert und nicht mit Delphoi64. Muss ich andere Uses einbinden und wenn ja wie?
Mit KI erhalte ich folgende Hinweise: (wahrscheinlich fette Texte)
Eine Fehlermeldung wie „Zugriffsverletzung bei Adresse FFFFFFFFAE50080D“ (Access Violation) in Delphi bedeutet im Kern, dass Ihr Programm versucht hat, auf einen Speicherbereich zuzugreifen, der ihm nicht gehört oder der zu diesem Zeitpunkt nicht (mehr) existiert.
In der Regel handelt es sich dabei um das Lesen oder Schreiben über einen ungültigen Zeiger (Pointer).
Warum ist die Adresse so lang? (FFFFFFFF...)
Die vielen Fs am Anfang der Adresse (FFFFFFFF...) sind ein typisches Zeichen dafür, dass es sich um eine 64-Bit-Anwendung (Win64) handelt. Bei 64-Bit-Systemen werden Adressen oft durch Vorzeichenerweiterung (Sign Extension) so dargestellt, wenn im negativen Adressraum oder in bestimmten Systembereichen operiert wird, oder wenn ein ungültiger Zeiger (wie -1 oder ein korrupter Speicherwert) verwendet wurde.
Die 4 häufigsten Ursachen in Delphi
(*
1. Nutzung eines nicht erzeugten Objekts (Nil-Pointer)
Sie versuchen, auf eine Methode oder Eigenschaft eines Objekts zuzugreifen, das noch gar nicht mit Create instanziiert wurde.
• Beispiel: Kunde.Name := 'Max'; aufgerufen, bevor Kunde := TKunde.Create; ausgeführt wurde.
2. Nutzung eines bereits freigegebenen Objekts (Dangling Pointer)
Das Objekt wurde bereits im Speicher gelöscht (z. B. via Free oder Destroy), aber das Programm versucht später erneut, darauf zuzugreifen.
• Tipp: Nutzen Sie FreeAndNil(Objekt); statt Objekt.Free;. Dadurch wird die Variable nach dem Löschen auf nil gesetzt. Wenn Sie dann fälschlicherweise darauf zugreifen, knallt es zwar meistens immer noch, aber bei einer sauberen Adresse wie 0000000000000000, was viel leichter zu debuggen ist.
*)
3. Indizierungsfehler bei Arrays oder Listen (Buffer Overflow)
Sie greifen auf ein Element in einem dynamischen Array, einer TList oder einer TStringList zu, das außerhalb der erlaubten Grenzen liegt (z. B. Zugriff auf Index 10, obwohl das Array nur 5 Elemente hat).
4. Fehler bei Windows-API-Aufrufen oder DLLs
Wenn Sie externe DLLs einbinden oder direkt mit der Windows-API kommunizieren, kann diese Meldung auftreten, wenn falsche Datentypen übergeben werden (z. B. wenn die DLL ein 32-Bit-Objekt erwartet, Delphi 13 es aber als 64-Bit-Objekt übergibt, oder umgekehrt).
