![]() |
Interfaces und nil setzen
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 :) |
AW: Interfaces und nil setzen
Zitat:
Delphi-Quellcode:
, nicht Membervariable. Ne, dann trifft 2. ebenfalls zu.
class var
|
AW: Interfaces und nil setzen
nee, mit 2. meinte ich einen Member der Klasse wie :
Code:
type MyClass = class
private IMyIntf : IMyInterface; end; |
AW: Interfaces und nil setzen
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. |
AW: Interfaces und nil setzen
Zitat:
Delphi-Quellcode:
Nachkommen.
IInterface/TInterfacedObject
Zitat:
|
AW: Interfaces und nil setzen
Zitat:
|
AW: Interfaces und nil setzen
Zitat:
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... |
AW: Interfaces und nil setzen
Zitat:
Delphi-Quellcode:
und
_AddRef
Delphi-Quellcode:
selbstverständlich nicht in der "Standardform" implementieren muss und
_Release
Delphi-Quellcode:
leitet diese Methoden einfach auf das unter
TComponent
Delphi-Quellcode:
hinterlegte Interface um (wenn vorhanden).
VCLComObject
Aber in dem Falle wäre doch die komplette Frage obsolet bzw. das geschilderte Verhalten würde gar nicht auftreten. Die Freigabe von
Delphi-Quellcode:
ist doch außerdem ganz strikt reguliert über das Ownership (
TComponent
Delphi-Quellcode:
Property).
Owner
|
AW: Interfaces und nil setzen
Zitat:
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. |
AW: Interfaces und nil setzen
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:38 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz