MemoryLeak bei Frame und TComboBox.Items.AddObject()

[Poelser]

Als Lösung würde ich das auch nicht bezeichnen, eher als Würgaround.

Klar sollte der Eigentümer des Frames ein Form oder ein Control á la TPanel sein und nicht die Applikation selbst. Ich hab' schon seit einiger Zeit nichts mehr mit Frames gemacht, kann mich aber aus D7-Zeiten noch daran erinnern, dass die Dinger sich oft irgendwie komisch verhalten haben

LG aus dem hohen Norden, Edmund

[himitsu]

Zitat:

Ein OnCreate() und OnDestroy() gibt es bei Frames ja leider nicht. Ich muss das Frame aber dynamisch erzeugen und es mit Werten füllen.

Dann aber mit override.
Am Speicherleck ändert es aber nichts. Beim Aufruf des Create über einen Vorfahrentypen würde dann die ComboBox einfach leer sein weil dem Vorfahren dein Create nicht bekannt ist über dessen "virtual". (z.B. wenn der Frame im Formdesigner auf die Form gepappt und in der DFM gespeichert wurde)

Haltepunkt in TFrame1.Destroy und schauen ob das Event aufgerufen wird und wenn ja, ob dort die Items der Combobox "noch" gefüllt sind.

Alternative:

Delphi-Quellcode:

  TTestObject = class(TComponent)
  ...

  TestObject := TTestObject.Create(cbb1);  // oder self oder wo immer es passt
  TestObject.TestProperty := 'Item 1';
  cbb1.Items.AddObject('Item 1', TestObject);

  // und das Free im Destroy kann entfallen

[Aviator]

Danke für deine Anteilnahme himitsu, aber du solltest meinen ersten Beitrag und auch die nachfolgenden Posts lesen. Dann wirst du merken, dass deine Vorschläge so alle nicht umsetzbar sind bzw. alles schon so durchgeführt wurde.

[himitsu]

Wie gesagt:

Zitat:

Haltepunkt in TFrame1.Destroy und schauen ob das Event aufgerufen wird und wenn ja, ob dort die Items der Combobox "noch" gefüllt sind.

[Aviator]

Zitat von himitsu:

Wie gesagt:

Zitat:

Haltepunkt in TFrame1.Destroy und schauen ob das Event aufgerufen wird und wenn ja, ob dort die Items der Combobox "noch" gefüllt sind.

Wie gesagt ... lies bitte meinen Post komplett und auch die der anderen Mitglieder ...
Post.jpg

[himitsu]

Also entweder waren "diese" Items schon immer leer (z.B. andere oder falsche Frame-Instanz oder dein Create nicht ausgeführt), oder das Leeren wurde vorher schon einmal ausgeführt (durch irgendwas ausgelöst *1).
Letzteres würde man mitbekommen, mit einem weiteren Haltepunkt in einem OnChange der Komponente.
Man könnte auch die VCL debuggen, aber wenn das Löschen nicht über eine Klassenmethode ala Items.Clear, sondern via Message direkt an Windows geht, dann bringt ein Haltepunkt in der VCL/TComboBox nicht viel.

1) Würde ich aber erstmal ausschließen, denn du scheinst ja keinen anderen Code zu haben, der die Items löscht.
Wenn, dann würde ich eher erwarten, dass bereits die komplette ComboBox gelöscht wurde und nicht nur die Items.

OnChange der ComboBox reagiert aber auf Text/ItemIndex.
Für ein Change-Event des Items müsste man wohl irgendeine Message abfangen.
* entweder ein Hook auf die/mehrere Setter-Message, welche die Items zuweist/löscht
* oder eine Notify-Message (falls es sowas gibt)
Findet man im MSDN/PSDK von Windows, wenn man schaut mit welcher Message TComboBox die Items z.B. beim Add an Windows übergibt, und was beim Hersteller dazu steht.



Man könnte auch ein Destroy in seine Datenklasse einfügen, darein einen Haltepunkt und dann schauen von wo die Freigabe her kam.
* entweder in diesem Frame/Combobox gab es nie Items (rausfinden warum nicht)
* oder das wird igentwo "falsch" freigeben (erstmal rausbekommen wo und dann warum)
Aber wenn die Speichelecks deine Klassen-Instanzen sind (sind sie das wirklich? ), dann wurde TTestObject.Destroy ja nicht aufgerufen und ein Haltepunkt dort hilft nichts.

[Aviator]

Ich habe ja schon an allen erdenklichen Stellen versucht Breakpoints zu setzen und den StackTrace anzuschauen. Was ich glaube ich nicht gemacht habe, ist die Destroy Methode meiner Klasse, die ich als Object hinzufüge, zu überschreiben und da mal einen Breakpoint reinzusetzen.

Das wäre wirklich noch eine Idee und einen Versuch wert. Werde ich morgen/heute mal ausprobieren.

Wenn du das selbst auch mal testen willst, dann kannst du natürlich gerne auch mal das Testprojekt aus meinem ersten Post herunterladen und es versuchen.

[Uwe Raabe]

Ich fürchte, mit deinem Ansatz wirst du nicht weit kommen. Die ComboBox verwaltet die ITEMDATA-Einträge selbst und offenbar werden die beim Schließen des Forms schon entfernt. Es gibt meines Wissens keinen Mechanismus um das zu umgehen ohne über OwnerDraw zu gehen. Selbst dann muss man die WM_DELETEITEM Message auch noch selbst abfangen und verarbeiten.

Wenn du die Kontrolle über die Items in der Combobox hast, dann kannst du die TTestObject-Instanzen auch über eine TObjectList<TTestObject> verwalten. Per Default ist dann die Liste für die Freigabe zuständig.