Problème Dispose et mémoire

Bonjour,
J'avais une question concernant le disposing des objets. j'ai actuellement un control1 avec dessus une centaine de controls2.
Bon déjà j'ai remarqué que le fait de faire control1.controls.clear ne dispose pas les objets dessus.
D'après ce que j'ai pu trouver dans mes recherches ils seront disposés tôt ou tard quand le système sera décidé x).
Quand je force le GarbageCollector il n'y a aucune libération de la mémoire qui est visible.

Pièce jointe 139262
(GC a été réalisé avec le deuxième pic bleu...)

Ensuite j'ai fait une fonction qui dispose tous les control2 un par un avant de les supprimer de control1. Puis je force le GC. La mémoire se libérè bien,...

Si j'ai bien comprit il est obligatoire de faire une fonction qui dispose les objets non managés qu'une classe utilise sinon il seront jamais disposés tout seuls ?
Je voulais aussi donc savoir comment ça se fait que la méthode dispose de mes controls est jamais appelée...

Merci d'avance

La méthode dispose est appelée si tu l'appelles, sinon elle n'est effectivement pas appelé.:aie:

Il y a effectivement un grand risque avec le controls.clear() qui ne dispose pas les objets ce qui cré souvent une fuite de mémoire.
Par contre une fois que tu les as dispoés tu n'es pas obligé d'appelé le GC. A moins que tu es vraiment besoin de la RAM sur un vieux pc...

Tu dois donc juste bien penser à disposer tes éléments.

Donc en gros oui tu as bien compris.

En aucun cas le dispose d'un control n'est appelé automatiquement Oo ?
Actuellement j' appel le dispose de tous les controls dans l'event disposed du usercotnrol parent. Est-ce une bonne pratique ? sachant qu'on ne peut pas implement idisposable ou override la fonction dispose parente.

Dans ton control tu peux normalement faire

Code:

---

1 2 3 4 5 6

Public Overloads Sub Dispose() 'ToDo My code   MyBase.Dispose() End Sub

---

Après je pense qu'un dispose est fait quand tu quittes ton application mais en cours de route il faut que tu t'en occupes pour les objets non manager ce qui est assez lourd au début quand on y pense pas.

il y a un peu de faux dans ce que dit chaparo



Dispose sur un controle appelle des dispose sur tous ses enfants, qui appelleront dispose sur leurs enfants etc...
c'est le code de la méthode Dispose de la classe control qui fait ca et tous les controles hérite de cette classe

Dispose est appelé même si on ne l'appelle pas (mais on ne sait pas quand)
en fait le gc a plusieurs "poches" de liens, et arrivés à je ne sais quel étage il appelle la méthode finalize qui appelle la méthode Dispose(false) dans l'implémentation standard de IDisposable proposée par microsoft
Dispose(false) fait moins de chose que Dispose(true) (qui lui est appelé quand on appelle Dispose tout court) mais ca devrait suffire quand même

même finalize n'a pas de garanti d'être appelé, en cas de plantage ou de fermeture d'appli (pas toutes) par exemple, en .net il n'y a pas vraiment de sens de destructeur obligatoire comme dans certains langages)
(cette phrase n'est pas de moi, et j'ose espérer que par là ils voulaient dire qu'on ne peut pas être sûr que du code qu'on y aurait mis sera exécuté, mais la mémoire doit être libérée par la clr, enfin j'espère)

ce n'est pas un overloads Dispose qu'il faut faire mais un overrides

quand on code une classe on peut implémenter IDisposable et appeler le dispose de nos variables disposables dans la méthode dispose

quand une instance n'est plus référencées toutes les variables sont mises à nothing, pour les dim dans les membres, c'est en sortie de membres qu'ils sont mis à nothing
ceci permet au GC de voir qui n'est lié à personne

le using / end using équivaut à un try finally qui dispose (forcément donc)

concernant le controls.clear il est à éviter quand on a beaucoup de controles, nous on s'est codé une méthode d'extension DisposeControlesEnfants sur la classe control
on peut donc écrire MonPanel.DisposeControlesEnfants (voir méthodes d'extension sur google, qui permet de rajouter des méthodes sur des classes qui ne sont pas à nous, comme celles du framework)

en bref, en général tout se passe bien, mais pour certaines choses il faut faire attention à ce qu'on écrit (controls.clear, bim b new bitmap géant dans une boucle etc...)

Merci beaucoup Pol63 pour cette réponse très complète.
Je viens effectivement de constater que le dispose d'un contrôle entrainait le dispose de ses contrôles enfant.
Sur un de mes controls j'ai eu la bonne idée de le créer par le designer ce qui fait que le dispose se retrouve dans du code généré. Aucun rapport avec le sujet mais il y a peut être moyen de le virer ? Et même dans une classe qui hérite Control j'arrive pas à mettre mon dispose.

Bon pour revenir au sujet.
J'ai beaucoup mieux compris cette histoire. Il me reste cependant une incompréhension au niveau des dispose.

Pour reprendre l'exemple du bitmap. Son dispose est obligatoire pour eviter le leak car bitmap utilise du code non manage genre des allocations de mémoire et tout. Mais pour une classe normale avec 3 variables dedans on a pas besoin de dispose car le code est entièrement managé et il sait direct comment supprimer la mémoire allouée à la classe. J’espère que je suis pas trop dans le faux x)

Merci.

Edit: Pour info j'ai trouvé le leak. Il venait d'un timer qui n'était pas disposé. Ça a l'air de rien mais au bout de beaucoup d'utilisations du logiciel ça fait plusieurs mega de leak Oo

Citation:

---

Envoyé par gaetan13

Sur un de mes controls j'ai eu la bonne idée de le créer par le designer ce qui fait que le dispose se retrouve dans du code généré. Aucun rapport avec le sujet mais il y a peut être moyen de le virer ? Et même dans une classe qui hérite Control j'arrive pas à mettre mon dispose.

---

pas compris

Citation:

---

Envoyé par gaetan13

Pour reprendre l'exemple du bitmap. Son dispose est obligatoire pour eviter le leak car bitmap utilise du code non manage genre des allocations de mémoire et tout. Mais pour une classe normale avec 3 variables dedans on a pas besoin de dispose car le code est entièrement managé et il sait direct comment supprimer la mémoire allouée à la classe. J’espère que je suis pas trop dans le faux x)

---

non managé = géré en dehors de .net
par exemple pour les images, microsoft n'as pas tout redévelopppé dans le framework (enfin ca doit être moins vrai en wpf)
du coup les images sont gérées par gdiplus.dll (donc windows) avec des classes dans le framework qui servent de "passerelle" entre les 2
autant que la mémoire est automatiquement nettoyée en .net, pour windows il faut l'avertir, ce que fait dispose
(les connexions sql sont gérées par des classes qui ne sont en .net non plus, et d'autres choses également)

Citation:

---

Envoyé par gaetan13

Edit: Pour info j'ai trouvé le leak. Il venait d'un timer qui n'était pas disposé. Ça a l'air de rien mais au bout de beaucoup d'utilisations du logiciel ça fait plusieurs mega de leak Oo

---

il y a en .net les components
component est une classe intermédiaire entre rien et control (windows.forms.timer hérite de component (il y a d'autres timers dans le framework))
component a aussi un dispose
quand on pose un component sur un form il y a du code associé dans le .designer, qui fait qu'il est disposé quand on dispose le form
pour des components créés dans le code il faut en effet penser à les disposer

Pièce jointe 139289
J'ai mon dispose qui est dans le designer, donc overrides pas possible vu que c'est comme s'il était déjà dans ma classe... Je suis sur que la solution est toute bête mais je vois pas :/ Si je modifie le code dans le designer il va me le réécrire je pense .

Donc du coup si on applique ça au timer, le timer doit appeler du code non managé lui aussi, c'est exacte ?

alors je crois qu'on peut écrire dans cet overrides de dispose
c'est surtout initializecomponent qui est regénéré
et si tu veux tu être sûr tu t'abonnes à me.disposed à la place, c'est exécuté pas longtemps après l'overrides de dispose (via les combobox en haut du code)

le timer ou un morceau de la classe component ...

Merci beaucoup :)

Bonjour, deux petits ajouts à tout ce qui a été dit :

* Si un finisseur doit être exécuté, le premier Collect ne fait que déplacer l'objet vers la file d'attente des finisseurs, la mémoire n'est pas encore récoltée. Si je ne m'abuse il faut faire Collect, WaitForPendingFinalizers, Collect (pas sûr que le second "collect" soit nécessaire). Attention de ne faire ça que pour le besoin des tests et à ne pas appeler Collect dans l'application livrée aux clients, les performances et la consommation mémoire en souffriraient !

* Si une fuite mémoire existe dans l'application (par exemple parce que des enfants désormais inutilisés avaient souscrits aux événements d'un parent qui existe toujours - les enfants sont donc toujours référencés par le parent), le finisseur ne sera jamais exécuté. Appeler dispose n'éliminera pas la fuite mémoire mais fera au moins en sorte que les ressources non-managées soient nettoyées, ce qui peut faire une très grosse différence sur la mémoire.

pour expliciter un de ces points, les addhandler doivent avoir un removehandler associé quelque part