Kein Zugriff auf Private Variablen

[Der schöne Günther]

Setze mal einen Haltepunkt bei

Delphi-Quellcode:

procedure TTestThread.RemoveThread;
begin
  gThreadManager.RemoveThread(Self)
end;

und denk mal nach

[Purri]

Hallo Günther,

ich sehe da leider kein Problem (Außer vll. das fehlende Semikolon, aber das macht keinen Unterschied ).

Wenn ich den Thread alleine beende, also per Klick auf den Thread-Stop-Button, funktioniert übrigens alles, auch das RemoveThread.

[bra]

Du übergibst in dem Thread Self an den Threadmanager und versuchst den zu Löschen (Free). Das kann nur schief gehen

[Der schöne Günther]

Dein gThreadManager ist zu dem Zeitpunkt schon nil da du vorher schon FreeAndNil(gThreadManager) gemacht hast.

[Purri]

Ok, ich verstehe was ihr meint, aber nicht warum das so ist.

Ich habe jetzt das FreeAndNil durch

Delphi-Quellcode:

  gThreadManager.Free;
  gThreadManager := nil;

ersetzt. nun klappt es.

Danke.

Zum Verständnis:
Ich befinde mich doch eigentlich immer noch im Destructor vom ThreadManager, also dürfte er doch nicht schon weg sein? Ein Blick in den FreeAndNil-Code zeigt: Zuerst wird := nil gesetzt und erst danach .Free aufgerufen.... Ich fühle mich von Delphi verar**** So isses doch wohl eher NilAndFree

Gibt es einen guten Grund, warum diese Reihenfolge ausgeführt wird?

[Blup]

Deine Instanz des ThreadManager existiert zu diesem Zeitpunkt noch. Nur der globale Zeiger "gThreadManager" auf diese Intstanz zeigt bereits auf nil. Zugriffe über nil-Pointer löst Zugriffsverletzung aus.

[Purri]

Danke Blub,
das habe ich verstanden und schon geändert. Ich frage mich nur noch, warum FreeAndNil zuerst den Zeiger löscht und dann die Instanz, anstatt es andersrum zu machen, wie ja auch der Name es vermuten lässt.

[bra]

Zu dem Sinn und Unsinn von FreeAndNil gibt es dutzende Diskussionen. Einige sagen, man sollte es oft verwenden, andere nie. Und ich glaube beide haben Recht