Warum gibt es hier eine Acess Violation?

[Benmik]

In einem Modul deklariere ich:

Delphi-Quellcode:

type
  TDing = class(TObject)
    Nr: integer;
  end;
  TDingliste = class(TObjectList<TDing>)
  ...
  ...
  end;

In einem anderen Modul verwende ich das:

Delphi-Quellcode:

procedure Test;
var Dingliste:TDingliste;

  procedure Initialisiere;
  begin
    Dingliste := TDingliste.Create;
  end;

  procedure HierKnallts;
  var Ding:TDing;
  begin
    Ding := TDing.Create;
    Ding.Nr := 1;
    Dingliste.add(Ding);  // Access Violation
  end;

begin
  Initialisiere;
  HierKnallts;
end;

Das verstehe ich nicht. Dingliste wird ordnungsgemäß erstellt und ist verfügbar. Nehme ich eine globale Variable für Dingliste, gibt es keine Probleme.

[Schokohase]

Also mit 10.3 Rio kann ich nichts feststellen, da gibt es keine Exception.

[Benmik]

Habe ich auch grad mal nachgebastelt, bei mir auch nicht. Dürfte ja auch gar nicht sein.
Woran könnte das theoretisch liegen?

[Schokohase]

Beliebt ist Ding.Create statt TDing.Create

[Benmik]

Oouuh, jetzt fällt mir eine mögliche Antwort selber ein.

Die Routine "HierKnallts" ist eine Callback-Routine, deren aufrufende Routine von einer weiteren Unterprozedur von "Test" aufgerufen und mit @HierKnallts übergeben wird.
Obwohl man im Debugger die Variable ohne weiteres sieht, erinnere ich mich, dass es da mit der Sichtbarkeit Probleme gab. Daher funktioniert auch die globale Variable.

[jaenicke]

Ich kann nur den Rat geben niemals Variablen oberhalb von Unterroutinen einer Methode zu deklarieren. Das führt nur zu Konfusionen. Man sollte die benötigten Variablen an Unterroutinen immer direkt mitgeben.

Sprich statt:

Delphi-Quellcode:

procedure Test;
var
  Dingliste:TDingliste;

  procedure HierKnallts;
  begin
    Dingliste.add(Ding);  // Access Violation
  end;

begin
  ...
  HierKnallts;
end;

Besser:

Delphi-Quellcode:

procedure Test;

  procedure HierKnallts(ADingliste: TDingliste);
  begin
    ADingliste.add(Ding);
  end;

var
  Dingliste: TDingliste;
begin
  ...
  HierKnallts(Dingliste);
end;

So kann man viel leichter debuggen was da wo schief geht...

Zitat von Benmik:

Die Routine "HierKnallts" ist eine Callback-Routine, deren aufrufende Routine von einer weiteren Unterprozedur von "Test" aufgerufen und mit @HierKnallts übergeben wird.
Obwohl man im Debugger die Variable ohne weiteres sieht, erinnere ich mich, dass es da mit der Sichtbarkeit Probleme gab. Daher funktioniert auch die globale Variable.

Wenn es Probleme mit der Sichtbarkeit gäbe, würde es nicht kompilieren. Alles andere was mit Sichtbarkeit zu tun hat, würde nur zu dem Problem führen, wenn es irgendwo eine zweite gleichnamige Variable geben würde.

[hoika]

Hallo,
dein Code ist bestimmt nur dem richtigen Code nachgestellt. .?
Ichbdenke, Du hast die Listenvariable doppelt deklariert.

[Uwe Raabe]

Zitat von jaenicke:

Man sollte die benötigten Variablen an Unterroutinen immer direkt mitgeben.

Das macht es auch wesentlich einfacher diese Unterroutinen in eigene Methoden zu extrahieren.

[Benmik]

@jaenicke
Dein Ratschlag ist sicher analog zu dem, wenn irgend möglich keine globalen Variablen zu verwenden. Dingliste wäre dann praktisch eine globale Variable für die Unterroutinen von "Test". Es ist aber doch auch so, dass dies ein Design-Ratschlag ist und keinerlei technische Nachteile hat? (Delphi lässt ja diese Konstruktion explizit zu!)

@Uwe Raabe: Könntest du das kurz erläutern?

Ich wäre dankbar, wenn ich dieses Phänomen, das ich eigentlich kenne, mal verstehen würde.

Um etwas auszuholen: Gerade um meinen Code übersichtlich zu halten, teile ich ihn in möglichst viele einzelne Aufgaben auf. Eigentlich ist das gute Programmierpraxis; es gibt einen Guru, der gefordert hat, eine Routine dürfe immer nur eine einzige Aufgabe erledigen; ich habe ihn mal bei Wikipedia nachgeschlagen, leider aber seinen Namen vergessen und ich finde ihn auf die Schnelle auch nicht wieder.

Wenn ich mir professionellen Code anschaue, dann habe ich noch nie verstanden, warum diese Jungs sich oft einen Sch... um dieses Prinzip kümmern. Ellenlange Routinen, möglichst noch nach den Delphi Style Guides, was den Text noch doppelt so lang macht. Eine Qual, das zu debuggen. Ebenfalls eine Qual ist es, wenn die Aufgaben zwar in Unterroutinen zerlegt wurden, aber jede Routine einzeln bzw. eine eigene Methode ist. Man springt beim Debuggen dann zu zahllosen Stellen im Code hin und her.

Ich zerlege daher die Aufgaben einer Routine in Einzelteile. Und wenn diese Aufgaben nur einmal im ganzen Code vorkommen (oft 90%), dann verlege ich sie in eine Unterroutine und gebe ihr einen aussagekräftigen Namen, bei dem Aussagekraft vor (englischer) Kürze geht. So verstehe ich auch nach Monaten und Jahren noch, was da passiert. Kein Wunder, dass meine absolute Lieblingsneuerung damals Code Folding war! Wenn möglich, besteht meine Hauptroutine nur aus den Namen der 10 Unterprozeduren. Dank Ctrl+Shift-K-P liegt das ganze Gebilde kompakt vor mir. Daher würde ich jaenickes Ratschlag auch nur äußerst ungern folgen, denn so kann ich den Weg einer Variablen durch die Unterprozeduren leicht verfolgen. Mit F8 gehe ich durch die 10 Zeilen mit den Namen der Unterprozeduren und sehe viel leichter, wo etwas geschieht, was ich nicht beabsichtigt habe.

OK, nun zur Sache. Auch im besagten Beispiel handelt es sich um eine Klassenmethode mit mehreren Unterroutinen. Das Original von "Test" ist eine Unterprozedur dieser Klassenmethode und heißt FindeDateien(VerzListe[i],'*',False,@FindeDateiRM,Abbrechen); . Sie ruft procedure FindeDateien(const BasisVerz,DateiMaske:string;MitUVerz:Boolean;FindeDateienRM:TFindeDateienRM;var Abbruch:Boolean); auf, das in einer anderen Unit liegt, keine Klassenmethode ist und die Callback-Routine procedure FindeDateiRM(const BasisVerz:string;const Data:TWin32FindDataW;var Abbrechen:Boolean); aufruft, die ebenfalls eine Unterroutine der Klassenmethode ist. In FindeDateiRM wird eine Instanz von TBld erzeugt, die Dateieigenschaften von TWin32FindDataW eingefüllt und die Instanz dann zur Objektliste TObjectList<TBld> hinzugefügt.

Also so:

In einem anderen Modul:

Delphi-Quellcode:

type
TFindeDateienRM = procedure(const Verzname:string;const Data:_WIN32_FIND_DATAW;var Abbr:Boolean); stdcall;

procedure FindeDateien(const BasisVerz,DateiMaske:string;MitUVerz:Boolean;FindeDateienRM:TFindeDateienRM;var Abbruch:Boolean);

Delphi-Quellcode:

procedure TForm1.ErstelleListe;
var Bldliste:TBldliste; 
begin

  procedure Intialisiere;
  begin
    Bldliste := TBldliste.Create(True);
  end;

  procedure FindeDateiRM(const BasisVerz:string;const Data:TWin32FindDataW;var Abbrechen:Boolean);
  var Bld:TBld;
  begin
    Bld := TBld.Create;
    Bld.Name := string(Data.cFileName);
    Bldliste.add(Bld); // Das will er nicht
  end;

  procedure ListeDateienAuf;
  begin
    FindeDateien(VerzListe[i],'*',False,@FindeDateiRM,Abbrechen); 
  end;

end;

Hier kommt es zu dem geschilderten Phänomen. Die TObjectList ist bei der Klassenmethode deklariert und im Debugger in allen Unterprozeduren sichtbar. Trotzdem kommt es zu einer Schutzverletzung, wenn ich keine globale Variable verwende. Was genau geschieht da?