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