VirtualTreeView et gestion mémoire

**free07** · 17/08/2021, 19h09

Bonjour

J'ai un programme qui utilise VirtualTreeView pour l'affichage d'une liste d'objet ( avec TObjectList), les objets sont ajoutés au VirtualTreeView par AddChild et c'est lui qui en est propriétaire.

OwnsObjects de TObjectList est à False car c'est le VirtualTreeView qui libère la mémoire de la liste des objets lorsqu'il est détruit.

Mais dans certains cas, j'aimerai pouvoir maitriser complètement la libération des objets de la liste : est il possible d'indiquer au VirtualTreeView de ne pas s'occuper de la libération mémoire ? dans ce cas, je pourrai mettre OwnsObjects à True et ce sera le TObjectList qui libérera la mémoire.

J'ai cherché sur le net mais je n'ai pas trouvé l'info.

**ShaiLeTroll** · 17/08/2021, 20h03

Il me semblait que le TVirtualTreeView gérait des pointeurs comme UserData et pas des objets
Faut dire que je ne l'ai jamais utilisé, j'ai regardé par curiosité en C++Builder, il y a dix ans.

D'ailleurs, à l'époque tout était TVirtualNode \ PVirtuaNode soit des record, la donnée utilisateur était dedans

**free07** · 18/08/2021, 08h58

Envoyé par ShaiLeTroll

Il me semblait que le TVirtualTreeView gérait des pointeurs comme UserData et pas des objets

Oui c'est vrai, je transmets au TVirtualTreeView la liste des pointeurs du TObjectList et je suppose que lorsque le TVirtualTreeView est détruit il supprime tous les pointeurs contenus dans les noeuds et je me dis que cela doit impacter les pointeurs du TObjectList, je me trompe ?

A la réflexion oui je me trompe, pour remplir les pointeurs sur les données du TVirtualTreeView on utilise une class et c'est les données de cette classe qui sont supprimées

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
// Node data record for the the document properties treeview.
 
PPropertyData = ^TPropertyData;
 TPropertyData = class
    Name : String;         
    ValueType: TValueType;
    Value: WideString;     
    Id : Integer;         
    Changed: Boolean;
    ImageId : Integer;    
    objet : TObject;      // Objet de la liste TObjectList
  end;
 
 
MonObjet : TObject;
MaListeObjet : TObjectList;
PropertyData : TPropertyData;
Node : PVirtualNode;
 
...
 
VirtualTreeView.NodeDataSize := SizeOf(TPropertyData);
for i:= 0 to MaListeObjet.count -1 do
begin
     MonObjet := TObject(MaListeObjet.Items[i]);
 
      PropertyData := TPropertyData.Create;
      PropertyData Name := MonObjet.Nom;
      PropertyData.ValueType := 0;
      PropertyData.objet := MonObjet;
     PropertyData.ImageId :=0 ;
 
     Node := TVirtualTreeView.AddChild(nil, PropertyData);  // On ajoute chaque noeud
end;

Donc la liste des objets du TObjectList n'est pas impactée, là je me trompe pas n'est ce pas ?

**ShaiLeTroll** · 18/08/2021, 11h03

La liste n'est pas impactée à la vision du code actuel
Cependant comme sont libérés les TPropertyData ? j'ai un doute que la libération soit automatique, un évènement OnDeletion comme sur le TTreeView ?

Le VirtualTreeView alloue et libère les PVirtuaNode incluant la mémoire utilisateur de la taille définie par NodeDataSize
Mais il ne sait pas libéré un pointeur typé

Quand tu défini TPropertyData en class, pour lui, c'est 4o en plus, et il va juste libérer les 4o mais en aucun cas appeler un Destroy ou un Dispose si cela avait été un pointeur de record, il n'a qu'un pointeur lambda non typé, il n'a pas la possibilité d'utiliser les RTTI pour finaliser les types record ou string pointés.

bizarre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MonObjet := TObject(MaListeObjet.Items[i]);
 PropertyData Name := MonObjet.Nom;

Tu n'as pas osé redéfinir TObject ?
MaListeObjet est TObjectList et donc Items[] est TObject, cast curieux

Un ReportOnMemoryLeak doit indiquer qu'un aucun TPropertyData n'est libéré car seule la consommation mémoire du pointeur en lui l'est !

En D7, je n'aurais pas eu de scrupule à faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
TPropertyData = packed record // un record non une class
    Name : String[255];         // pas de pointeur que des types simples 
    ValueType: TValueType;
    Value: String[255];  // Cast en WideString ultérieur  
    Id : Integer;         
    Changed: Boolean;
    ImageId : Integer;    
    objet : TObject;      // Objet de la liste TObjectList, weak référence
  end;

Grace à NodeDataSize l'allocation des PVirtuaNode aurait contenu directement toutes les données sans pointeurs (String étant un pointeur)
J'évalue SizeOf(TPropertyData) à 256 + 4 + 256 + 4 + 1 + 4 + 4 = 529 (ça dépend la taille de l'enum TValueType et des options de compilation sur la taille minimale des enum)

En D10, avec l'unicode, le String[255] est un risque de perte de donnée (si l'on travaille dans une application Française et Chinoise en simultané par exemple)
TPropertyData on le laisse en class
Par flemme, une TObjectList<TPropertyData> en OwnsObject comme GarbageCollector

**free07** · 18/08/2021, 13h20

Envoyé par ShaiLeTroll

La liste n'est pas impactée à la vision du code actuel
Cependant comme sont libérés les TPropertyData ? j'ai un doute que la libération soit automatique, un évènement OnDeletion comme sur le TTreeView ?

C'est avec un Clear du VirtualStringTree, de ce que j'ai pu voir dans le code source, ils font un FreeMem de chaque noeud

Envoyé par ShaiLeTroll

bizarre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MonObjet := TObject(MaListeObjet.Items[i]);
 PropertyData Name := MonObjet.Nom;

Tu n'as pas osé redéfinir TObject ?
MaListeObjet est TObjectList et donc Items[] est TObject, cast curieux

Oui en fait j'ai oublié de préciser que c'est TMonObjet qui cast :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Node data record for the the document properties treeview.
 
PPropertyData = ^TPropertyData;
 TPropertyData = class
    Name : String;         
    ValueType: TValueType;
    Value: WideString;     
    Id : Integer;         
    Changed: Boolean;
    ImageId : Integer;    
    objet : TObject;      // Objet de la liste TObjectList
  end;
 
TMonObjet : class (TObject)
...
end;
 
MonObjet : TMonObjet;
MaListeObjet : TObjectList;
PropertyData : TPropertyData;
Node : PVirtualNode;
 
...
 
VirtualTreeView.NodeDataSize := SizeOf(TPropertyData);
for i:= 0 to MaListeObjet.count -1 do
begin
     MonObjet := TMonObject(MaListeObjet.Items[i]);
 
      PropertyData := TPropertyData.Create;
      PropertyData Name := MonObjet.Nom;
      PropertyData.ValueType := 0;
      PropertyData.objet := MonObjet;
     PropertyData.ImageId :=0 ;
 
     Node := TVirtualTreeView.AddChild(nil, PropertyData);  // On ajoute chaque noeud
end;

Envoyé par ShaiLeTroll

Un ReportOnMemoryLeak doit indiquer qu'un aucun TPropertyData n'est libéré car seule la consommation mémoire du pointeur en lui l'est !

Il faut que je regarde comment utiliser les ReportOnMemoryLeak, j'ai installé la version gratuite de fastMM4

Envoyé par ShaiLeTroll

En D7, je n'aurais pas eu de scrupule à faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
TPropertyData = packed record // un record non une class
    Name : String[255];         // pas de pointeur que des types simples 
    ValueType: TValueType;
    Value: String[255];  // Cast en WideString ultérieur  
    Id : Integer;         
    Changed: Boolean;
    ImageId : Integer;    
    objet : TObject;      // Objet de la liste TObjectList, weak référence
  end;

Grace à NodeDataSize l'allocation des PVirtuaNode aurait contenu directement toutes les données sans pointeurs (String étant un pointeur)
J'évalue SizeOf(TPropertyData) à 256 + 4 + 256 + 4 + 1 + 4 + 4 = 529 (ça dépend la taille de l'enum TValueType et des options de compilation sur la taille minimale des enum)

En D10, avec l'unicode, le String[255] est un risque de perte de donnée (si l'on travaille dans une application Française et Chinoise en simultané par exemple)
TPropertyData on le laisse en class
Par flemme, une TObjectList<TPropertyData> en OwnsObject comme GarbageCollector

Sur ce projet, j'utilise Delphi 10.2, merci pour toutes tes précisions !

**ShaiLeTroll** · 18/08/2021, 15h11

Si D10, c'est inclu ReportMemoryLeaksOnShutdown
RTLMM de D10 est une version simplifie de FastMM4 (euh 4.72 je crois)

Dans le DPR, je mets ceci, le message de log n'est affiché qu'un Debug sous Delphi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{$IFDEF DEBUG}
{$WARN SYMBOL_PLATFORM OFF}
  System.ReportMemoryLeaksOnShutdown := DebugHook <> 0;
{$WARN SYMBOL_PLATFORM ON}
{$ELSE DEBUG}
  System.ReportMemoryLeaksOnShutdown := False;
{$ENDIF DEBUG}

Mais si tu as trop de fuite mémoire, si le log dépasse 32Ko, cela échoue à l'affichage donc là faut FastMM4 pour la version fichier du log.

Sinon, comme je disais le FreeMem libère le PVirtuaNode (soit SizeOf(TVirtuaNode) + NodeDataSize) mais ne libère pas le TPropertyData

Tu peux aussi écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part