Object (Interface) <> nil

[EWeiss]

Zu 1.
Es gibt keinen Destructor da hier jemand gesagt hat das ich das Interface nicht selbst auf NIL setzen kann.
Daher benötige ich den nicht.

Zu 2.
Ja im Contructor wird die Variable SkinPopUpMenu := self; zugewiesen.

Zitat:

Dann kannst Du jederzeit auf Assigned(gMyPopupMenu) prüfen...

Und genau das mache ich in der DLL um zu prüfen ob das Object (Interface wie auch immer) frei ist.

Damit habe ich aber der Anwendung immer noch nicht mitgeteilt das mein Object Nil ist.

Danke für eure Hilfe werde das wohl selbst regeln müssen.
Ohne Vollständigen Code nutzt euch das nichts da ihr nicht sehen könnt was abgeht.

gruss

[Neutral General]

Anwendung:

Delphi-Quellcode:

var popup: ISkinPopUpMenu;
begin
  popup := CTRL_PopUpMenuCreate(OnPopupDestroyed);
end;

procedure OnPopupDestroyed()
begin
  ShowMessage('Popup wurde in der DLL auf nil gesetzt!');
end;

DLL:

Delphi-Quellcode:

var 
  CallbackZurAnwendung: TCallback;

function CTRL_PopUpMenuCreate(callback: TCallback): ISkinPopUpMenu; stdcall;
begin
  result := TSkinPopUpMenu.Create();
  CallbackZurAnwendung := callback;
end;

// ...
// Wenn das Popupmenu auf nil gesetzt wird:
CallbackZurAnwendung(PopupMenu);
PopupMenu := nil;

[EWeiss]

Danke werde es mal testen
Wenn dann ist das wohl die beste Lösung ohne zusätzliche Funktionen.

gruss

[stahli]

In jedem Fall würde ich den Destructor an Deiner Stelle überschreiben.
Du musst ja darin neben dem inherited nichts tun und Du musst ja Free auch nicht aufrufen, aber so kannst Du bei Bedarf mal einen Haltepunkt setzen und sehen, ob und wann Dein Objekt wirklich freigegeben wird (einfach nur zur Ablaufkontrolle).

Und Du solltest m.E. auch nicht davon sprechen, ob ein Objekt oder Interface = Nil ist, sondern ob eine Variable Nil ist.
Das ist auch zum eigenen Verständnis bei solchen Problemen wichtig, da es ja mehrere Variablen geben kann, die ein Objekt referenzieren.
Auch ändert die Objektfreigabe nichts an diesen Variablen. Lediglich Zugriffe auf diese können später unvorhersehbare Probleme bis hin zum Programmabsturz verursachen.

[EWeiss]

Zitat:

In jedem Fall würde ich den Destructor an Deiner Stelle überschreiben.
Du musst ja darin neben dem inherited nichts tun und Du musst ja Free auch nicht aufrufen, aber so kannst Du bei Bedarf mal einen Haltepunkt setzen und sehen, ob und wann Dein Objekt wirklich freigegeben wird (einfach nur zur Ablaufkontrolle).

leere funktion die nichts tut ?
Wenn du meinst das ist besser werde ich es addieren.

Zitat:

Und Du solltest m.E. auch nicht davon sprechen, ob ein Objekt oder Interface = Nil ist, sondern ob eine Variable Nil ist.

Verstehe ich nicht ganz einzelne Variablen ? Wenn doch das Interface aus mehreren besteht.

gruss

[stahli]

Im Destructor muss man natürlich inherited aufrufen.
Ich finde das übersichtlicher, diesen auch zu überschreiben wenn man Konstruktoren definiert (ist aber nur Gewohnheitssache).
Aber Du kannst halt einen Haltepunkt setzten und sehen, ob das Objekt überhaupt freigegeben wird und wann.


Zu den Objekten und Interfaces, schau mal, ob Dir das zum Verständnis hilft: http://www.delphipraxis.net/1288384-post13.html

Wenn Du auf ein Interface zugreifst, ist das letztlich der Zugriff auf ein Teilstück eines Objektes. Das ist also ein etwas eingeschränkter Zugriff auf die Daten und Methoden des Objektes.

Das hat aber mit Variablen direkt nichts zu tun.

Was ich sagen wollte ist, dass eine Freigabe eines Objektes keine Variable auf Nil setzt und eine Zuweisung von Nil an eine Variable kein Objekt (bzw. keinen Speicherplatz) freigibt. (Die einzige Ausnahme ist bei Verwendung der automatischen Referenzzählung und Zuweisung von Nil an die letzte referenzierende Variable. Die Referenzzählung bezieht sich dabei immer auf das Objekt hinter den Interfaces - also bei zwei Referenzen auf Interface A und 2 auf Interface B eines Objektes erhöht die Referenzzählung des Objektes auf 4. Es gibt nicht je zwei Referenzzählerwerte auf Interface A und B.)

Die Trennung von Objektfreigabe und Variablenreferenz = NIL muss man gerade bei so einer Problemlösungssuche trennen, weil man sich sonst sprachlich einfach nicht verstehen kann.
MyIntf := Nil; kann zu einer Auflösung des Objektes führen oder auch nicht.
Auf eines von beiden zu reagieren sind zwei verschiedene Paar Schuhe.

[EWeiss]

Danke dir für die Infos..

gruss