MemoryLeak bei Frame und TComboBox.Items.AddObject()

[Aviator]

Hallo Delphianer,

ich bin seit ein paar Tagen nun dran, eine Anwendung zu bauen die Daten in eine Datenbank einträgt welche wiederum von einem Service abgearbeitet werden sollen.

In der Anwendung habe ich nun ein Frame erstellt das dynamisch auf der Form platziert wird und auf dem mehrere ComboBoxen vorhanden sind. Eine davon wird dynamisch mit Hilfe von TComboBox.Items.AddObject() gefüllt, da ich noch diverse Zusatzinformationen beim Auswählen des Items brauche. Jedoch bekomme ich beim Beenden der Anwendung mehrere MemoryLeaks angezeigt. Um genau zu sein, genau so viele MemoryLeaks wie ich Items eingefügt habe.

Ich konnte das Problem auch mit einer einfachen Test Anwendung, die ihr im Anhang findet, nachstellen. Wenn das Frame erzeugt und die Anwendung direkt danach mit Hilfe des Schließen X geschlossen wird, erscheint ein MemoryLeak. Wird das Frame manuell über den zweiten Button freigegeben passiert nichts.

Wenn man einen Breakpoint im TFrame1.Destroy setzt, ist der Item Count der ComboBox im ersten Fall bereits 0. Ich habe schon die wildesten Breakpoints in den Delphi internen Sourcen gesetzt. Die Reihenfolge wie diese abgearbeitet wurden ist in meinen Augen auch korrekt. Nur leider finde ich keine Stelle, an der die Items "frühzeitig" gelöscht werden.


Die Frage wäre jetzt, ob ich grundsätzlich etwas falsch mache bei der Verwendung von Frames. Bspw. das Überschreiben von Create() und Destroy(). Ich meine mal gelesen zu haben, dass man das nicht machen sollte. Allerdings finde ich da nichts mehr zu und im Endeffekt ist es ja auch nur ein TWinControl. Allerdings nutze ich Frames in ganz anderen, teils viel größeren, Anwendungen und hatte noch nie Probleme. Auch nicht beim Überschreiben der genannten Methoden. Nur im Zusammenhang mit der ComboBox habe ich scheinbar kein Glück.

Wäre super, wenn sich das mal jemand anschauen und ggf. etwas dazu sagen kann. Ich habe keine Idee mehr wo ich noch suchen sollte.

[Der schöne Günther]

Ohne im Detail geschaut zu haben:

Delphi-Quellcode:

constructor Create(AOwner: TComponent); reintroduce;

Das ist bestimmt nicht was du willst.

Versuche doch einmal mit eigenen Worten zu beschreiben weshalb du dem Konstruktor ein

Delphi-Quellcode:

reintroduce

und dem Destruktor (korrekterweise) ein

Delphi-Quellcode:

override

verpasst hast. Vielleicht kommst du dann schon direkt drauf.

[Aviator]

Naja ... in meiner Hauptanwendung muss ich dem Constructor noch einen weiteren Parameter mitgeben (s. unten).

Delphi-Quellcode:

override

funktioniert ja in dem Fall nicht, da ich dann die Meldung erhalte, dass sich die Deklaration des Constructors von der vorherigen Deklaration unterscheidet. Daher

Delphi-Quellcode:

reintroduce

. Wenn das falsch sein sollte, dann bitte ich um Erleuchtung wie man das richtig machen könnte. :)

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

Delphi-Quellcode:

constructor Create(AOwner: TComponent; ASettings: ISettings); reintroduce;

[Poelser]

Moin,

ja, ich kann mit Delphi 10.2 das Speicherleck nachvollziehen.

Ich habe dann mal den Create mit Application statt Self ausgeführt, also

Delphi-Quellcode:

  FMainFrame := TFrame1.Create(Application);

und es gibt kein Speicherleck mehr.

LG aus dem hohen Norden, Edmund

[Aviator]

Zitat:

Zitat von Poelser (Beitrag 1478237)

Moin,

ja, ich kann mit Delphi 10.2 das Speicherleck nachvollziehen.

Ich habe dann mal den Create mit Application statt Self ausgeführt, also

Delphi-Quellcode:

  FMainFrame := TFrame1.Create(Application);

und es gibt kein Speicherleck mehr.

LG aus dem hohen Norden, Edmund

Danke für den Test. :thumb:

Aber das sollte ja denke ich nicht die Lösung sein. Es müsste ja möglich sein, dass ich eine Form oder gar ein Panel oder whatever als Owner für das Frame angeben kann, ohne das ich hunderte Memory Leaks bekomme.

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

Delphi-Quellcode:

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:

Zitat von himitsu (Beitrag 1478261)

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 ...
Anhang 53369

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

[himitsu]

Jupp, in den Notification-Events (CBN_*) gibt es wirklich nichts, was den Inhalt der Items betrifft. :cry:

https://docs.microsoft.com/en-us/win...ls/combo-boxes

[Aviator]

Zitat:

Zitat von Uwe Raabe (Beitrag 1478273)

Ich fürchte, mit deinem Ansatz wirst du nicht weit kommen.

Ja stimmt. Jetzt wo ich so drüber nachdenke. Die ComboBox gibt die Items ja eben nicht frei.

Nur die Frage die sich mir jetzt stellt ist: Warum gibt es keine MemoryLeaks, wenn ich das Frame manuell freigebe anstatt das vom Owner machen zu lassen?

Wenn es hierfür keine Lösung gibt, dann wäre es auch kein Problem stattdessen eine TObjectList<T> zu verwenden und die dann je nach ItemIndex auszulesen. Nur stelle ich mir eben schon die Frage wieso sich das hier so verhält.

[himitsu]

Es kommt wohl drauf an, was zuerst freigegeben wird.
Die Delphi-Komponente (TComboBox/TWinControl) oder die Windows-Komponente (HWND).
Wird z.B. zuerst das HWND der Form freigegeben, dann reißt das alle untergeordneten HWND mit, bevor die Delphi-Controls freigegeben werden.

Beim Selbstfreigeben ist dein Aufräumcode immer meistens zuerst dran, bevor der nachfolgende Code das HWND freigibt.



Dass es keine Events/Notifications gibt, erklärt dann auch, warum Delphi in diesem Items kein OwnsObjekts anbietet.
Via Owner oder in einer anderen TList/TObjectList/TComponentList deine TTestObject's zu verwalten wird dann wohl die einzige Lösung sein.

[Uwe Raabe]

Zitat:

Zitat von Aviator (Beitrag 1478275)

Nur die Frage die sich mir jetzt stellt ist: Warum gibt es keine MemoryLeaks, wenn ich das Frame manuell freigebe anstatt das vom Owner machen zu lassen?

Weil beim DestroyWindowHandle des Forms schon indirekt der Count der Combobox-Items auf 0 gesetzt wird und das TFrame1.Destroy ins Leere läuft; bei der manuellen Freigabe aber erst das Destroy ausgeführt wird, was dann im inherited erst die ComboBox freigibt.

Du kannst übrigens die MemoryLeaks vermeiden, wenn du das Frame schon im FormDestroy-Event freigibst anstatt auf die implizite Freigabe zu warten. Das DestroyWindowHandle wird nämlich erst danach ausgeführt.

[himitsu]

Sonst hat die VCL überall eine Kopie der Daten, damit die erhalten bleiben, auch wenn noch/grad kein Handle existiert.
Aber ausgerechnet hier nicht. :roll:

Man könnte ein eigenes TComboBoxStrings benutzen, was diesen "Makel" beseitigt.

[Aviator]

Tja sehr schade, dass bei einem Frame eine solche Ausnahme gemacht wird. Ich bin mir sicher, dass das bei einer normalen Form so nicht passiert. Ich nutze die Objects in einer ComboBox zwar nicht übermäßig oft, aber doch schon häufiger. Und so ein Problem ist mir bis jetzt noch nicht untergekommen.

Ich werde meinen SourceCode an der Stelle dann wohl auf eine

Delphi-Quellcode:

TObjectList<T>

umbauen und die Elemente selbst verwalten. Ist in dem Fall dann wohl einfacher.

Aufgefallen ist es mir aber wie immer nur deshalb, weil ich die möglichen Fehler eines zukünftigen Users natürlich schon bei der Entwicklung abfangen will. Der Fehler erscheint eben nur dann, wenn er einen neuen Job anlegen will, dann das Fenster aber einfach direkt schließt ohne vorher die Erstellung abzubrechen.

Immer diese User ... 80% des SourceCodes ist ja bekanntlich nur daher von Nöten, um die Fehler derjenigen abzufangen. :wink:


Danke an alle Beteiligten.

[himitsu]

Wenn sich der Parent ändert (z.B. kurz nil ist), dann kann das Handle eventuell freigegeben werden,
und auch beim Hide (Visible=False) oder Application.Minimize geben einige Komponenten ihre Handle frei (inkl. der Handle aller Unterkomponenten, weil Windows diese gleich mit löscht).
-> Sparmaßnahmen, weil die Komponente eh nicht sichtbar ist ... oder wenn eine Komponente ohne Parent nicht existieren kann

Hier ein paar Methoden/Ereignisse/Eigenschaften, die dein Problem betreffen. (TWinControl: alle Forms und sichtbaren Komponenten mit einem HWND)

Delphi-Quellcode:

procedure CreateHandle; virtual;
procedure CreateParams(var Params: TCreateParams); virtual;
procedure CreateWindowHandle(const Params: TCreateParams); virtual;
procedure CreateWnd; virtual;
procedure DestroyHandle; virtual;
procedure DestroyWindowHandle; virtual;
procedure DestroyWnd; virtual;
procedure RecreateWnd;
function HandleAllocated: Boolean;
procedure HandleNeeded;
property WindowHandle: HWnd read FHandle write FHandle;
property Handle: HWND read GetHandle;

So kann man CreateWnd überschreiben und beim Erstellen/Neuerstellen drauf reagieren.
z.B. wenn man bei einer Komponente/Fenster das Drag&Drop aktiviert hat, was man beim Neuerstellen wiederherstellen muß.