Impossible de libérer une stringlist dynamiquement créée

Bonjour,

J'ai encore un truc à m'arracher les cheveux, heureusement qu'ils repoussent vite !

Je veux récupérer des noms de dossiers et des noms de fichiers depuis un TShellTreeView pour les insérer dans une TListbox, enfantin me direz-vous.
Oui, c'est ce que je croyais, j'ai donc attaqué avec 4 lignes juste pour voir si l'idée fonctionnait, ce qui est le cas, mais mal, car je ne peux pas libérer les TStringList's créées...
La preuve :
J'ai lancé le projet et j'ai cliqué sur 3 nœuds, à la clôture j'ai gagné 9 unfreed memory block.
J'ai recommencé avec 4 clics et là, 12 unfreed memory blocks, donc 1 clic = 3 unfreed blocks et voilà le code ultra-simple à l'origine de cette embrouille :

Code:

---

1 2 3 4 5 6 7 8

function TForm1.ListDirectory(SelectedNode {as FolderSource}: string): TStrings; var sl: TStringList; begin sl:= TStringList.Create; sl.Add(SelectedNode); // pour test Result := sl; // ok // sl.Destroy; //sl.Free; //l'un comme l'autre = erreur end;

---

Pièce jointe 641865
En pas à pas, ça se produit au end; de fin de fonction.

La manière d'appeler cette fonction :

Code:

---

1 2 3 4 5 6

procedure TForm1.stvClick(Sender: TObject); begin lbFonts.Items := ListDirectory(stv.GetPathFromNode(stv.Selected)); // GetPathFromNode returns the path (including the file name) // from the file system that a particular node represents. end;

---

Ça fonctionne, les données que j'attends se retrouvent bien dans la listbox, c'est juste ces fuites qui me perturbent.
Quelque chose d'énorme doit m'échapper, mais je ne vois pas quoi...

Ce que je vois, par contre, dans l'aide et que je ne comprend pas, c'est l'absence de Free, mais comme vous le voyez dans le code, un essai avec Destroy retourne la même erreur.

J'ai jeté un œil à la pile d'appel, mais c'est ardu (dernière entrée en haut) :

Code:

---

1 2 3 4 5 6 7

#0 SYSTEM$_$TOBJECT_$__$$_INHERITSFROM$TCLASS$$BOOLEAN at :0 #1 fpc_do_is at :0 #2 ?? at :0 #3 ASSIGN(0x7ffff60b2200, 0x7ffff60b4e00) at gtk2int.pas:612 #4 SETITEMS(0x7ffff5734ef0, 0x7ffff60b4e00) at include/customlistbox.inc:587 #5 STVCLICK(0x7ffff6403790, 0x7ffff5730f10) at unit1.pas:139 <-- c''est bien la ligne qui appelle la fonction ListDirectory sur l''événement stvClick. avant c''est pas intéressant

---

Alors, si quelqu'un a une idée, merci de la poster...

Les fuites sont logiques puisque tu crées des listes que tu ne libères pas.
Le problème est que si tu les libères, Result devient invalide puisqu'il partage la même allocation ; d'où la VA.

Tu dois mémoriser le pointeur retourné et le libérer une fois assigné à la ListBox.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

procedure TForm1.stvClickClick(Sender: TObject); var List :TStrings; begin List := ListDirectory(stv.GetPathFromNode(stv.Selected));   try lbFonts.Items.Assign(List); finally List.Free; end; end;   function TForm1.ListDirectory(SelectedNode: string): TStrings; begin Result := TStringList.Create; Result.Add(SelectedNode)); end;

---

Mais des créations à gauche et des libérations à droite n'est pas exceptionnel. Plus simplement, passe ListBox.Items en paramètre (comme tu l'as vu dans d'autres fonctions dernièrement), la méthode appelée se contentant de la remplir.

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.stvClickClick(Sender: TObject); begin ListDirectory(stv.GetPathFromNode(stv.Selected), lbFonts.Items); end;   procedure TForm1.ListDirectory(SelectedNode: string; aList :TStrings); begin aList.Add(SelectedNode); end;

---

Citation:

---

Envoyé par Andnotor

... Result devient invalide puisqu'il partage la même allocation

---

Je me doutais, au vu du comportement de mes lignes de code, qu'il s'agissait d'un truc comme ça, mais j'étais à des années-lumière de le corriger aussi bien que tu l'as fait.
T'es vraiment un cador, hein ! :plusser: :ccool:

Moi je pensais bêtement que Result := sl; se contentait de mettre les données de sl dans Result, un peu comme quand je donne une pièce de monnaie à quelqu'un, la pièce je ne l'ai plus et le quelqu'un s'en va et peut l'utiliser.
Bah...

Bonne journée et encore merci,

Citation:

---

Envoyé par Jipété

T'es vraiment un cador, hein !

---

Arrête ! tu vas me faire :oops:

Citation:

---

Envoyé par Jipété

Moi je pensais bêtement que Result := sl; se contentait de mettre les données de sl dans Result, un peu comme quand je donne une pièce de monnaie à quelqu'un, la pièce je ne l'ai plus et le quelqu'un s'en va et peut l'utiliser.

---

Mais c'est un peu ça à part qu'ici il ne donne pas une pièce (un item) mais tout le porte-monnaie (l'allocation complète) ;)
Pour être plus précis, ils partagent le même porte-monnaie et si un le jette l'autre ne peut plus l'utiliser non plus.

L'incompréhension vient plutôt du comportement des propriétés qui implémentent des accesseurs (getter/setter = encapsulation) comme ListBox2.Items := ListBox1.Items qui se traduit en fait par ListBox2.SetItems(ListBox1.FItems), SetItems lançant lui-même un Assign pour la copie de la données (ce que tu retrouves dans la pile d'appels lors de l'erreur).

Mais ceci n'a pas cours ici puisqu'une copie de pointeur n'est pas orientée objet ;)