Prüfen, ob Referenz auf tatsächlich existentes Objekt zeigt

[Rob09]

Hi!

Okay, folgendes:

Wenn ich prüfen möchte, ob ein Objekt existiert, dann kann ich ja einfach folgendes abfragen:

if Assigned(ReferenzAufObjekt) then ... .

Das funktioniert aber nur dann, wenn ich beim zerstören des Objekts FreeAndNil(ReferenzAufObjektObjekt) verwende (oder halt ReferenzAufobjekt := nil ).

Wenn ich allerdings das Objekt nur mit ReferenzAufObjekt.Free zerstöre, dann liefert Assigned(...) ja weiterhin True.

Gibt es denn irgendeine Möglichkeit, auch dann zu prüfen, ob das Objekt, auf das ReferenzAufObjekt zeigt, tatsächlich existiert oder schon zerstört wurde?

Beste Grüße!
Robert

[Luckie]

Ja, drauf zugreifen und wenn es kracht, existiert es nicht. aber wenn du um die Problematik weißt, warum gibst du es dann nicht ordentlich frei?

[Sir Rufo]

Zitat von Luckie:

Ja, drauf zugreifen und wenn es kracht, existiert es nicht. aber wenn du um die Problematik weißt, warum gibst du es dann nicht ordentlich frei?

So richtig ordentlich frei geben macht er ja wohl, aber er hat womöglich an anderen Stellen die Referenz noch gespeichert und dann hat er sich dort den Boden unter den Füßen weggezogen.

Somit bleibt dann wohl nur ein TInterfacedObject oder das Anwendungsdesign nochmal zu überdenken.

[Rob09]

Das tu ich deshalb, weil ich einen TThread benutze, der sich durch .FreeOnTerminate = True selbst zerstört, wenn er fertig ist (vgl. http://www.delphipraxis.net/163566-c...ch-noetig.html). Dabei wird die Referenz auf selbigen aber nicht nil gesetzt.

An Anderer Stelle möchte ich prüfen, ob der Thread noch läuft - dafür würde ich das oben nachgefragte dann brauchen.

Problem ist, dass ich mich etwas scheue, in der OnTerminate -Prozedur des Threads die Referenz auf ihn nil zu setzen, da es durch CoUninitialize etwas dauern kann, bis der Thread terminiert. Da der Aufruf zum Terminate aus der OnClose -Prozedur des Hauptfensters kommen kann (das nicht Thread.WaitFor abwartet, bevor es schließt), habe ich etwas Angst, was dabei passieren könnte.

[omata]

Wie wäre es mit einem Event, dass beim Beenden des Threads eine Prozedur aufruft, die die globale Variable auf den Thread auf nil setzt?

[Rob09]

@omata:

Du meinst also beim "regulären" Fertigwerden des Threads? Leider kann es auch sein, dass der Thread mit .Terminate abgebrochen wird, ohne dass das Programm geschlossen wird. In dem Fall müsste dann auch dafür gesorgt werden, dass die Referenz nil gesetzt wird. Wenn der .Terminate-Aufruf dann allerdings doch beim Schließen des Hauptfensters geschieht, stehe ich wieder vor dem oben beschriebenen Problem.

Oder habei ch dich falsch verstanden?

[omata]

Ja, genauso meine ich das.
Überschreib doch Terminate und sorge so dafür, dass das Event eben doch vorher noch ausgeführt wird.

[Rob09]

Ah, sehr gute Idee!

Werde mich morgen (also heute wenns hell wird ) mal ransetzen und dann Bericht erstatten.

Vielen Dank an alle bis hierher und gute Nacht!
Robert

[Rob09]

Okay, dabei dann doch noch eine Frage:

Wenn ich aus dem MainThread heraus das .Terminate des NebenThreads aufrufe, führt dann der MainThread den Code, der dabei in eventuellen OnMyTerminate-Events steht, aus (was ich meine ist, ob dieser Code dann zuerst ausgeführt wird und erst danach die Befehle, die im MainThread nach NebenThread.Terminate noch kommen)?

[omata]

Die Befehle in der ThreadEnd-Prozedur werden nicht vom MainThread ausgeführt, sondern von NebenThread und damit ist ein Kritischer Abschnitt erforderlich oder ein Synchronize.