AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi MemoryLeak bei Frame und TComboBox.Items.AddObject()

MemoryLeak bei Frame und TComboBox.Items.AddObject()

Ein Thema von Aviator · begonnen am 30. Nov 2020 · letzter Beitrag vom 1. Dez 2020
Antwort Antwort
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.750 Beiträge
 
Delphi 12 Athens
 
#1

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 30. Nov 2020, 23:24
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.531 Beiträge
 
Delphi 12 Athens
 
#2

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 30. Nov 2020, 23:38
Jupp, in den Notification-Events (CBN_*) gibt es wirklich nichts, was den Inhalt der Items betrifft.

https://docs.microsoft.com/en-us/win...ls/combo-boxes
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.611 Beiträge
 
Delphi 10.3 Rio
 
#3

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 30. Nov 2020, 23:38
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.531 Beiträge
 
Delphi 12 Athens
 
#4

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 30. Nov 2020, 23:58
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.
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu ( 1. Dez 2020 um 00:07 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.750 Beiträge
 
Delphi 12 Athens
 
#5

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 1. Dez 2020, 08:54
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.531 Beiträge
 
Delphi 12 Athens
 
#6

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

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

Man könnte ein eigenes TComboBoxStrings benutzen, was diesen "Makel" beseitigt.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.611 Beiträge
 
Delphi 10.3 Rio
 
#7

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 1. Dez 2020, 11:54
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 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.


Danke an alle Beteiligten.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.531 Beiträge
 
Delphi 12 Athens
 
#8

AW: MemoryLeak bei Frame und TComboBox.Items.AddObject()

  Alt 1. Dez 2020, 12:06
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ß.
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu ( 1. Dez 2020 um 12:08 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz