Mal eine Frage, weil ich gerade so ein Problem hatte und es besser verstehen will...

Ich habe Frames und Datamodules, die interfaces haben. Frames werden dynamisch in ein Fenster-Bereich (Panel zum Bsp.) reingeladen und das form kennt das frame selbst nicht, nur das interface.
Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

ich habe aber wiederrum an anderen lokalen Stellen auch interfaces die ich nicht auf nil setze, aber die bereiten mir scheinbar keine Probleme.

Also, kann man es so zusammenfassen :

1. Interface globale variable : immer explizit auf nil setzen vor dem Programm ende, wenn das zugehörige Objekt freigegeben wird
2. Interface variable ist Klassenvariable : wenn die klasse zerstört wird, wird das interface freigegeben (ref counter runtergesetzt ?)
3. lokale Variable innerhalb einer procedure : wird auch dem stack angelegt und beim verlassen der procedure wieder der ref counter runtersetzt ?

Danke schonmal

Zitat von MyRealName:

1. Interface globale variable : immer explizit auf nil setzen vor dem Programm ende, wenn das zugehörige Objekt freigegeben wird
2. Interface variable ist Klassenvariable : wenn die klasse zerstört wird, wird das interface freigegeben (ref counter runtergesetzt ?)
3. lokale Variable innerhalb einer procedure : wird auch dem stack angelegt und beim verlassen der procedure wieder der ref counter runtersetzt ?

1. und 3. stimmen soweit (wobei Delphi Objekte nie auf dem Stack anlegt, aber dennoch automatisch das Interface Released, wenn es lokal war). 2. ist "glaube" ich nicht korrekt. Achso, class var , nicht Membervariable. Ne, dann trifft 2. ebenfalls zu.

nee, mit 2. meinte ich einen Member der Klasse wie :

markieren

Code:

type MyClass = class
     private
       IMyIntf : IMyInterface;
     end;

Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Zitat von Schokohase:

Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um IInterface/TInterfacedObject Nachkommen.

Zitat von MyRealName:

nee, mit 2. meinte ich einen Member der Klasse wie :

markieren

Code:

type MyClass = class
     private
       IMyIntf : IMyInterface;
     end;

Die sollten eigentlich nicht automatisch freigegeben werden.

Zitat von Zacherl:

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um IInterface/TInterfacedObject Nachkommen.

Tipp: Schau dir mal an was TInterfacedPersistent macht..

Zitat von Zacherl:

Zitat von Schokohase:

Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um IInterface/TInterfacedObject Nachkommen.

Du hast insofern Recht, als dass immer die _AddRef/_Release Methoden aufgerufen werden.

Ob die implementierende Klasse damit etwas anfängt, hängt ... von der implementierenden Klasse ab.

TFrame, TDataModule, ... das hört nicht nach Nachfahren von TInterfacedObject an. Die leiten sich von TComponent ab und das kümmert sich um die Zählung und automatische Freigabe bei 0 Referenzen einen feuchten P...

Zitat von Schokohase:

TFrame, TDataModule, ... das hört nicht nach Nachfahren von TInterfacedObject an. Die leiten sich von TComponent ab und das kümmert sich um die Zählung und automatische Freigabe bei 0 Referenzen einen feuchten P...

Natürlich hast du Recht, dass man _AddRef und _Release selbstverständlich nicht in der "Standardform" implementieren muss und TComponent leitet diese Methoden einfach auf das unter VCLComObject hinterlegte Interface um (wenn vorhanden).

Aber in dem Falle wäre doch die komplette Frage obsolet bzw. das geschilderte Verhalten würde gar nicht auftreten. Die Freigabe von TComponent ist doch außerdem ganz strikt reguliert über das Ownership (Owner Property).

Zitat von MyRealName:

Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

Das hört sich so an als würde dein Datenmodul direkt das Interface implementieren. Davon würde ich abraten, wenn es so ist, da deine Interfacereferenz noch weiterleben kann, wenn das Objekt zerstört wurde (automatisch per Owner oder auch manuell).
Beim Programmende kommt aber die Deinitialisierung dieser Interfaces, aber wenn das Objekt dahinter schon zerstört wurde, knallt es ggf. beim Aufruf von _Release.

Wir haben das so gelöst, dass unsere visuellen Komponenten und Datenmodule lediglich durch ein Interface gesteuert werden. Wird das Objekt freigegeben, wird die Referenz darauf im Interfaceobjekt auf nil gesetzt, aber das Interfaceobjekt lebt weiter. Man kann nicht mehr viel damit machen, aber man kann dies sauber abfangen und prüfen. Und vor allem hat man noch alle Daten usw., da diese nicht in der visuellen Komponente stecken, sondern in einem weiteren Interface, das sowohl die visuelle Komponente als auch das Interfaceobjekt kennen.

Zitat von jaenicke:

Zitat von MyRealName:

Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

Das hört sich so an als würde dein Datenmodul direkt das Interface implementieren. Davon würde ich abraten, wenn es so ist, da deine Interfacereferenz noch weiterleben kann, wenn das Objekt zerstört wurde (automatisch per Owner oder auch manuell).
Beim Programmende kommt aber die Deinitialisierung dieser Interfaces, aber wenn das Objekt dahinter schon zerstört wurde, knallt es ggf. beim Aufruf von _Release.

Wir haben das so gelöst, dass unsere visuellen Komponenten und Datenmodule lediglich durch ein Interface gesteuert werden. Wird das Objekt freigegeben, wird die Referenz darauf im Interfaceobjekt auf nil gesetzt, aber das Interfaceobjekt lebt weiter. Man kann nicht mehr viel damit machen, aber man kann dies sauber abfangen und prüfen. Und vor allem hat man noch alle Daten usw., da diese nicht in der visuellen Komponente stecken, sondern in einem weiteren Interface, das sowohl die visuelle Komponente als auch das Interfaceobjekt kennen.

IM Event Datamodule.OnCreate habe ich das interface gesetzt mit "Supports", aber durch unwissen im OnDestroy nicht entladen. Jetzt mache ich es und es fährt alles sauber runter wieder. Deswegen ja die Frage in welchen kombinationen man es manuell freigeben muss und wann nicht, um meinen Code nach möglichen problemen zu durchsuchen