TInterfacedObject-Nachfahren explizit freigeben?

[Andreas Kreul]

Guten Tag,

Ich möchte meinen in traditionellem OOP geschriebenen Code automatisierbar machen, deshalb bastele ich gerade daran, alle meine Klassen anstelle von TObject von o.g. Klasse abzuleiten, um den Zugriff per COM zu ermöglichen.

Bei der Freigabe meiner Objekte bin ich nun auf ein Problem gestossen:
Ein per COM angesprochenes Objekt wird freigegeben, wenn keine Referenzen durch Interfaces auf dieses Objekt mehr bestehen.
Eine automatische Freigabe wird aber bei meiner Objektstruktur nie erfolgen, weil ich die einzelnen Objekte sich untereinander referenzieren lasse (z.B. über eine Eigenschaft Owner).

Wie löse ich also dieses Problem? Hat jemand eine Idee?

Mit freundlichen Grüssen,

Andreas Kreul
Abt. Org/IT, Programmierung
KÖTTER GmbH & Co. KG Verwaltungsdienstleistungen
Wilhelm-Beckmann-Str. 7
45307 Essen-Germany

<mailto:[email protected]>
Telefon: +49 (201) 2788-151
Telefax: +49 (201) 2788-401
<http://www.koetter.de/>

[Andreas Kosch]

Hallo,

&gt;Wie löse ich also dieses Problem?

indem das private Objektfeld für den Interface-Zeiger, das über die Eigenschaft <i>Owner</i> abgefragt werden kann, auf nil gesetzt wird. Die Frage ist doch, muss die ganze Zeit eine statische Objektinstanz laufen? Wenn nicht, kann die Eigenschaft Owner beim ersten Zugriff prüfen, ob der Interface-Zeiger noch nil ist - wenn ja, wird eine COM-Objektinstanz angefordert und zurückgeliefert. Und wenn der "Verbraucher" dieses Objekt nicht mehr benötigt, könnte das über eine zweite Methode mitgeteilt werden. Zum Beispiel stellt Microsoft im Objektmodell von Word die Methode <i>Quit</i> zur Verfügung, mit der ein Client explizit sagen kann, dass er eine Objektinstanz nicht mehr braucht. Wenn innerhalb von Quit die Interface-Variable auf nil gesetzt wird, räumt sich die betroffene COM-Objektinstanz selbst ab

[Andreas Kreul]

Danke für die schnelle Antwort.

Zitat:
>indem das private Objektfeld für den Interface-Zeiger, das über die >Eigenschaft Owner abgefragt werden kann, auf nil gesetzt wird.

Ich hatte bereits befürchtet, daß ich so vorgehen muss. Mir erscheint diese Variante ein wenig unschön, da ich ja in diesem Falle eine Methode im Interface deklarieren muss, die Operationen durchführt, welche eigentlich nur im Falle der Freigabe eines Objekts ausgeführt werden und deshalb auch nur im Destruktor stehen sollten...

Es gibt also keine Möglichkeit, trotz der COM-Vorgaben Herr über die Lebenszeit eines erstellten Objektes zu werden?

Mit freundlichen Grüssen,

Andreas Kreu

[Andreas Kosch]

Hallo,

&gt;..Es gibt also keine Möglichkeit...

jedenfalls keine "legale" Möglichkeit - selbstverständlich könnte die Klasse die Objektinstanz auf dem VCL-Weg über <b>Free</b> abräumen, da alle Teile im gleichen Sourcecode liegen, wenn die Instanz direkt über Create angefordert wurde. Aber auch hier wird ein Zeitpunkt benötigt, d.h. die Klasse muss einen Weg vorsehen, über den mitgeteilt wird, dass eine bestimmte Objektinstanz nicht mehr benötigt wird und daher abgeräumt werden kann. Außerdem handelt man sich zusätzlichen Aufwand ein, da der VCL-Zugriffsweg mit dem COM-Zugriffsweg vermixt wird, so dass eigene _AddRef- und _Release-Aufrufe notwendig werden. Ich würde daher nur den "legalen" COM-Weg nutzen