Classe/Interface aus WinProc aufrufen

[stahli]

Sorry, ich kann Deine Fragen nicht ausreichend nachvollziehen.

Sind das zwei Threads zu zwei verschiedenen Projekten?
Existiert das Problem der Nicht-Freigabe im anderen Thread noch - und wenn, dann in dem anderen Projekt oder nur in diesem hier?

Wenn die Fragestellung nicht eindeutig klar ist, kann man darauf natürlich auch nicht hilfreich antworten.

Aber ich orakle mal etwas...

Wenn Du eine Interfacevariable MyPopupMenu hast, und dann noch eine Interfacevariable MySubMenu dann könnten diese u.U. gegenseitige Referenzen aufeinander halten.

Also falls Du so etwas machen solltest wie:
MySubMenu.RegisterOwnerPopupMenu(MyPopupMenu) und darin dem MyPopupMenu auch das SubMenu zugewiesen wird,
dann halten beide eine Referenz aufeinander. Es kann dann keine automatische Freigabe mehr erfolgen, weil Interface1 in Interface2 referenziert wird und somit nicht freigegeben werden kann, weil noch eine Referenz existiert und andersrum auch.

Um das aufzulösen, müsste man eine der beiden zirkulären Referenzen auflösen (z.B. MySubMenu.UnregisterOwnerPopupMenu(MyPopupMenu)).

Vielleicht sind ja solche hängenden oder zirkulären Referenzen Dein Problem.

Wie gesagt, so von außen ist das schwer zu beurteilen.

[EWeiss]

Zitat:

Sind das zwei Threads zu zwei verschiedenen Projekten?
Existiert das Problem der Nicht-Freigabe im anderen Thread noch - und wenn, dann in dem anderen Projekt oder nur in diesem hier?

Ich habe 2 Projekte

KVPlayer, OTTB

Beide verwenden das gleiche Interface.
KVPlayer mit SubMenus
OTTB ohne

KVPLayer gibt alle Reverenzen korrekt frei.
OTTB nicht.

So nun bin ich am Rätzeln denn eigentlich wäre das Problem verständlich wenn OTTB mit Submenu laufen würde.
Das gibt es hier aber nicht und trotzdem wird die Reverenz nicht freigegeben.

Also beide verwenden das selbe Interface das eine geht das andere nicht.

gruss

[stahli]

Ah, ok.
Dann tippe ich wirklich auf gegenseitige Referenzierung.

Wenn das Submenu sein Hauptmenu kennt (also ein einem Property oder ein einer Liste speichert) und auch das Hauptmenu sein Submenü verwaltet (was ja zu vermuten ist ) dann wird genau dieses Problem vorliegen.


Quatsch. In der Eile hatte ich das falsch gelesen.
Also dann wir es im OTTB noch irgendeine Referenz geben, der nicht NIL zugewiesen wird.

Das zu finden kann aufwendig werden.

[EWeiss]

Zitat:

Dann tippe ich wirklich auf gegenseitige Referenzierung.

Kann nicht sein denn wenn kein Submenu existiert dann wird diesbezüglich auch nichts Referenziert.
Keine einzige Variable die damit im Zusammenhang stehen könnte wird dann verwendet oder initialisiert.

gruss

[stahli]

Habe das gerade korrigiert.

Ich schreibe hier schnell mal parallel während der Arbeit. Da bin ich manchmal nicht konzentriert genug.

Dann musst Du mal schauen, wo da noch eine Referenz gehalten wird.

[EWeiss]

Zitat von stahli:

Habe das gerade korrigiert.

Ich schreibe hier schnell mal parallel während der Arbeit. Da bin ich manchmal nicht konzentriert genug.

Dann musst Du mal schauen, wo da noch eine Referenz gehalten wird.

Dank für deine Hilfe..
Werde ich wohl selbst fixen müssen wie auch immer.

gruss

[TiGü]

Delphi-Quellcode:

TSkinPopUpMenu = class(TInterfacedObject, ISkinPopUpMenu...)
   ...
  protected
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  public
   ...
end;

...

function TSkinPopUpMenu._AddRef: Integer;
begin
  Result := inherited _AddRef;
end;

function TSkinPopUpMenu._Release: Integer;
begin
  Result := inherited _Release;
end;

Dann in den eigenen _AddRef und _Release Haltepunkte setzen und vergleichen.
Irgendwo gibt es das Ungleichgewicht.

Fortgeschrittenen-Tipp:
Haltepunkte setzen aber in den Eigenschafen Break/Anhalten deaktivieren und den Call Stack mitloggen in der Ereignisanzeige: