COM: TInterfacedObject-Nachfahren explizit freigeben

[Udontknow]

Hi! Danke für die schnelle Antwort!

Also,
mit Garbage-Collection meinte ich auch kein COM-Feature, sondern das Feature von Delphi, das ja, sobald eine IInterface-Variable Out-Of-Scope geht bzw. auf NIL gesetzt wird, eben die Routine _Release aufruft. Genau das ist die Problematik!

Zu 1.
Habe ich auch probiert. Alle Zeiger auf untergeordnete Objekte auf NIL setzen. So weit so gut, aber was ist, wenn die inneren Objekte sich daraufhin nicht zerstören (z.B. weil ein Client, der mein Programm automatisieren will, per COM-Schnittstelle eben noch eine Referenz auf ein untergeordnetes Objekt hat)? Dann ist zwar die Referenz vom Hauptobjekt zum Detailobjekt weg, aber das Detailobjekt schwirrt aufgrund der noch vorhandenen Referenz durch irgendein anderes unbestimmbares Client-Objekt noch immer im Speicher herum. Der Client könnte an dem Objekt Manipulationen vornehmen, ohne zu wissen, das dieses Objekt gar nicht mehr Bestandteil der eigentlichen Anwendung ist.

Zu 2.
Das ist ja der Knackpunkt, es gibt keine Möglichkeit, die Referenzen von ausserhalb zu ermitteln! Nur die Anzahl der Referenzen wird mir von TInterfaced-Object bereitgestellt. Ich habe keine Chance, sämtliche Objekte zu ermitteln, die ein Interface auf eines meiner Objekte haben.
Ich habe auch schon versucht, _Addref und _Release aussen vor zu lassen, indem ich diese Methoden übersteuere und dort nichts tue, und einfach das Objekt per Free freizugeben, aber das bewirkt dann (vermutlich aufgrund dieser Delphi-Garbage-Collection) Zugriffsschutzverletzungen direkt nach Beendigung des Destruktors.

Zu 3.
Dann ist meine Applikation aber nicht mehr automatisierbar im Sinne von COM, und das ist ja gerade das Ziel! Im Moment übergebe ich tatsächlich überall nur Objektzeiger im Sinne von TMeinObjekt, und das macht auch gar keine Schwierigkeiten, da ich eben die Gewalt über die Lebenszeit aller Objekte habe.
Aber jetzt, wo ich auf COM umstellen will, stehe ich vor einem grossen Problem. Wenn bei traditionellem OOP irgendwo Referenzen auf ein schon freigegebenes Objekt vorliegen, kommt es bei Benutzung derer zu einer Zugriffsschutzverletzung, und das wars. Bei COM allerdings kann man munter weiter mit den Objekten arbeiten, bis dann plötzlich ganz merkwürdige Fehler auftreten!

Verzwickte Situation...

Cu,
Udontknow