Object (Interface) <> nil

[EWeiss]

Ich erstelle ein Menu basierend auf Interface.

In der Anwendung..

  PopUpMenu := CTRL_PopUpMenuCreate;

function CTRL_PopUpMenuCreate(): ISkinPopUpMenu; stdcall; external dllfile;
usw..

Ich möchte nichts anderes als meiner Anwendung mitteilen das dass erstellte Object Nil ist.
Und nicht Quasi aus einer Laune heraus das erstelle Interface in der Anwendung selbst auf Nil setzen.

Zitat:

"Wer es erstellt, der gibt es auch frei"?

richtig nur ein Standard Menu macht das nicht oder?
Es liefert keine Funktion zurück welche da sagt hallo bin fertig du kannst mich platt machen.


gruss

[Neutral General]

Warum ist das Objekt denn nil?
Wenn es erst gar nicht erstellt werden konnte kannst du ja mit CTRL_PopUpMenuCreate einfach "nil" zurückgeben.
Falls das Erstellen aber geklappt hat, dann gibt es keinen Grund warum du als DLL der Anwendung mitteilen müsstest dass das PopupMenu nil ist.
Denn entweder hat die Anwendung das selbst angeordnet oder die DLL hat sich eingemischt und das Popup der Anwendung freigegeben was genau dem widerspricht was ich oben gesagt hab.

Die Anwendung hat CTRL_PopUpMenuCreate aufgerufen also bleibt das erstelle PopupMenu solange erhalten bis die Anwendung es zerstört.

Alternativ kannst du vllt bei CTRL_PopUpMenuCreate als Parameter ein Callback übergeben lassen was die Anwendung informiert wenn das erstellte PopupMenu zerstört wurde.
Das wäre noch eine akzeptable Alternative denk ich.

[EWeiss]

Zitat:

Warum ist das Objekt denn nil?

Hat niemand etwas von gesagt das es Nil ist

Delphi-Quellcode:

function CTRL_PopUpMenuCreate(): ISkinPopUpMenu; stdcall;
begin

  result := TSkinPopUpMenu.Create();
end;

das schlägt niemals fehl.
Mit CTRL_PopUpMenuCreate wird nur das Interface erstellt.

Was fehl schlagen könnte ist wenn das Window nicht erstellt wird.
Nach dem alle benötigten Funktionen gefüllt wurden wird das Window erstellt.

Delphi-Quellcode:

  gPMenu.hPopUpHandle := PopUpMenu.CreatePopupMenu(WinHandle);
  if gPMenu.hPopUpHandle <> 0 then
  begin

und liefert ein HWND zurück.

Das ist aber nicht mein Problem sondern ich sage es nochmal PopUpMenu auf Nil zu setzen wenn in der DLL TSkinPopUpMenu ebenfalls Nil ist.
Und das ganze wenn möglich ohne zusätzliche Funktionen da ich versuche das verhalten des originalen Menus zu emulieren.

Scheint so das mich keiner versteht.

gruss

[TiGü]

Zitat von EWeiss:

Das ist aber nicht mein Problem sondern ich sage es nochmal PopUpMenu auf Nil zu setzen wenn in der DLL TSkinPopUpMenu ebenfalls Nil ist.
Und das ganze wenn möglich ohne zusätzliche Funktionen da ich versuche das verhalten des originalen Menus zu emulieren.

Scheint so das mich keiner versteht.

Du bist eben auch kein Erklärbär.

Speicherst du dir irgendwo (in einer globalen Variablen) das Objekt mit dem Typ TSkinPopUpMenu in der DLL ab?
Und auf dieses rufst du dann TSkinPopUpMenu.Free auf?

[EWeiss]

Zitat:

Und auf dieses rufst du dann TSkinPopUpMenu.Free auf?

Nein ich rufe überhaupt kein Free auf. (Habe es geändert da man das nicht tun soll)

Das Interface ist dann frei wenn alle Referenzen auf 0 sind.
Also ich beende alle Ressourcen und zerstöre alle Objecte (Windows usw..) die vom Interface verwendet werden.
Danach ist dieses automatisch frei..

gruss

[TiGü]

Zitat von EWeiss:

Zitat:

Und auf dieses rufst du dann TSkinPopUpMenu.Free auf?

Nein ich rufe überhaupt kein Free auf. (Habe es geändert da man das nicht tun soll)

Das Interface ist dann frei wenn alle Referenzen auf 0 sind.
Also ich beende alle Ressourcen und zerstöre alle Objecte (Windows usw..) die vom Interface verwendet werden.
Danach ist dieses automatisch frei..

Dein Problem ist also damit gelöst?

[Neutral General]

Zitat von EWeiss:

Das Interface ist dann frei wenn alle Referenzen auf 0 sind.
Also ich beende alle Ressourcen und zerstöre alle Objecte (Windows usw..) die vom Interface verwendet werden.
Danach ist dieses automatisch frei..

Ist das nicht trotzdem genau das Problem von dem ich die ganze Zeit rede?
Die DLL macht das von der Anwendung angeforderte Objekt selbstständig und ohne dass die Anwendung es angefordert hat komplett unbrauchbar bzw. gibt alles frei.
Genau das soll die DLL nicht machen. Entweder du gibst das Objekt/die vom Objekt benutzen Resource erst frei wenn die Anwendung das von sich aus anfordert oder du teilst der Anwendung per Callback (wie weiter oben von mir vorgeschlagen) mit dass das Popupmenu was es eben erstellt hat jetzt kaputt ist.

[stahli]

Zitat von EWeiss:

Ich möchte nichts anderes als meiner Anwendung mitteilen das dass erstellte Object Nil ist.

Um hier helfen zu können, müsste erst mal klar sein, wer das erstelle Objekt auf Nil setzt.
Das ist letztlich schon die falsche Beschreibung. Ein Objekt kann nicht auf Nil gesetzt werden. Dieses kann man höchstens freigeben (also dessen Speicherbereich wiederverwendbar machen).
Eine Variable kann man auf Nil setzen.

Willst Du also erkennen, ob das Objekt freigegeben wurde oder ob eine Variable auf Nil gesetzt wurde?

Eine diesbezügliche Interaktion zwischen DLL und Anwendung wird wohl in beiden Fällen nicht gehen (es sei denn, es würde ein Interface-Property als Informationsstelle benutzt).

Wenn die DLL außen vor bleiben kann und nur die Anwendung über die Objekt-Existenz informiert sein muss, gibt es mehrere (ziemlich triviale) Möglichkeiten.


Wenn Du die "Existenz Deines Objektes" nur in der Anwendung abfragen musst, die auch die Klasse (nicht nur das Interface kennt), und immer nur eine Instanz davon existieren kann, könntest Du eine Klassenvariable PopupMenuExist: Boolean; einrichten und diese im Constructor auf True und im Destructor auf False setzen.
Dann könntest Du abfragen, ob eine gütige Instanz existiert oder nicht.

Das setzt aber nicht Deine Variable auf Nil.
Dazu könntest Du evtl. eine globale Variable verwenden, die im Constuctor auf Self und im Destructor auf Nil gesetzt wird.

Oder Du folgst dem General und regelst die Rückinfo über ein Callback.


[EDIT]
Zusammenfassend die Frage: Wird aktuell der Destructor Deiner TPopupMenu-Klasse korrekt aufgerufen (egal unter welchen genauen Umständen)? Dann halte dort den Status für die Anwendung fest. Bestenfalls in einer globalen Variable gMyPopupMenu := Nil und im Contructor gMyPopupMenu := Self.
Dann kannst Du jederzeit auf Assigned(gMyPopupMenu) prüfen...
Das geht problemlos, wenn immer nur eine Instanz dieser Klasse leben kann.

[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;