Vous pouvez vérifier s'il reste des gestionnaires d'événements.
Dans le cas où vous avez enregistré un événement dans un autre contrôle, le collecteur garbadge ne collectera pas les objets qui ne sont plus nécessaires, car l'événement est toujours attaché pour ainsi dire.
Donc, si vous avez enregistré quelque part Loaded dans le code derrière
public ParentEditor()
{
InitializeComponents();
control.Loaded += OnControlLoaded;
}
ou en XAML ou ParentControl
<Control Loaded="OnControlLoaded" />
Vous avez basiquement deux solutions pour résoudre ce problème:
Solution 1 - Supprimez les gestionnaires d'événements lorsqu'ils ne sont plus nécessaires:
Vous pouvez supprimer ce gestionnaire dans le déchargement du contrôle des parents comme ceci:
public ParentEditor()
{
InitializeComponents();
control.Loaded += OnControlLoaded;
this.Unloaded += OnParentUnloaded;
}
void OnParentUnloaded(object sender, RoutedEventArgs e)
{
//Remove unloaded event
this.Unloaded -= OnParentUnloaded;
//Remove event from child control
control.Loaded -= OnControlLoaded;
}
Vous pouvez également utiliser l'événement Déchargé du contrôle des enfants bien sûr .. qui est à vous ..
solution 2 - Utilisation du modèle WeakEvent:
Une autre solution pour des événements serait le modèle WeakEvent, qui contourne ce problème.
Pourquoi implémenter le modèle WeakEvent?
L'écoute d'événements peut entraîner des fuites de mémoire . La technique typique pour écouter un événement est d'utiliser la syntaxe spécifique à la langue qui attache un gestionnaire à un événement sur une source . Par exemple, en C#, cette syntaxe est: source.SomeEvent + = new SomeEventHandler (MyEventHandler).
Cette technique crée une référence forte à partir de la source d'événements vers l'écouteur d'événements .Habituellement, attacher un gestionnaire d'événements pour un écouteur provoque l'écouteur pour avoir un objet durée de vie qui a été influencé par l'objet durée de vie pour la source (sauf si le gestionnaire d'événements est explicitement supprimé). Mais dans certaines circonstances, vous pourriez voulez la durée de vie de l'objet de l'auditeur à contrôler que par d'autres facteurs, comme si elle appartient actuellement à l'arbre visuel de l'application, et non par la durée de vie de la source . Lorsque la durée de vie de l'objet source s'étend au-delà de la durée de vie de l'objet de l'écouteur, le modèle d'événement normal conduit à une fuite de mémoire : l'écouteur est maintenu en vie plus longtemps que prévu.
Dans les deux cas, bonne chance .. son tout à fait difficile de trouver des fuites comme celui que vous rencontrez!
Merci pour les conseils - très utile! Mais avec MVVM, les gestionnaires d'événements ne sont même pas utilisés. Le viewmodel ne sait rien sur le gui, et expose seulement les commandes pour que le gui s'y accroche. – bluebit