Discussion :

[NeoKript]

Bonsoir à tous,

j'ai un petit soucis lors de l'utilisation d'un mediator.

J'ai une classe Plugin qui contient ceci :

Code :

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

1
2
3
4
5
6
7
8
public void Associate(String Identifiant, String Header, String Content)
        {
            Messenger.Instance.Register(Identifiant, delegate
            {
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + Header);
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + Content);
            });
        }

Et une classe loader qui contient :

Code :

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

1
2
3
4
5
6
7
8
public class Loader : Plugin
    {
        public Loader()
        {
            this.Namespace = "Cinema.Plugin";
            this.Associate("Add", "/Headers/HeaderAdd.xaml", "/Contents/Add.xaml");
        }
    }

Lorsque le message "Add" est emis, la méthode n'est pas appelé car il semblerait que l'objet ne soit plus en vie (qu'il ai été collecté alors qu'il ne l'est pas).

Maintenant, si je fait ceci à la place :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class Loader : Plugin
    {
        public Loader()
        {
            this.Namespace = "Cinema.Plugin";
            Messenger.Instance.Register(Identifiant, delegate
            {
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + "/Headers/HeaderAdd.xaml");
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + "/Contents/Add.xaml");
            });
        }
    }

Tout fonctionne à merveille, pouvez vous me dire quel est le problème lorsque que je met le Register dans la classe mère ?? (qui est dans une autre assembly, je sais pas si ça peut jouer).


Merci d'avance.

Cordialement,
NeoKript

[tomlev]

J'ai peut-être une idée, mais sans garantie que c'est bien ça le problème...

La classe Messenger utilise le pattern WeakEvent, pour éviter les fuites mémoires. Cela signifie qu'il ne conserve pas de références fortes aux handlers des messages, mais seulement des WeakReference. Comme tu t'abonnes au message avec une méthode anonyme qui capture des variables locales, le compilateur crée (de façon "invisible" pour toi) un nouvel objet anonyme qui va contenir ces variables. Mais toi, tu passes juste le delegate à la méthode Register, et tu ne conserves pas de référence à l'objet anonyme. Il n'existe donc aucune référence à cet objet, et donc rien qui l'empêche d'être collecté.

(certes, ça n'explique pas pourquoi ça fonctionne dans le 2e cas...)

A priori, si tu utilisais une "vraie" méthode au lieu d'une méthode anonyme, ça devrait fonctionner. Mais vu que tu as besoin de capturer des variables locales, ça ne va pas être possible...

Une autre solution serait de garder une référence vers le delegate lui-même, pour éviter que l'objet ne soit collecté. Un truc dans ce style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Action _registeredAction;
 
public void Associate(String Identifiant, String Header, String Content)
        {
            Action action = delegate
            {
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + Header);
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + Content);
            }
            Messenger.Instance.Register(Identifiant, action);
            _registeredAction = action;
        }

Il faudrait peut-être plutôt faire ça avec une liste d'action, vu que je suppose que la méthode Associate sera appelée plusieurs fois...

[NeoKript]

Salut,

Et merci pour ta réponse.
En effet, le problème viens de là !

Je viens de tester ceci :

Code :

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

1
2
3
4
5
6
7
8
9
public void Associate(String Identifiant, String Header, String Content)
        {
            Messenger.Instance.Register(Identifiant, Param => this.SetContent());
        }
 
        private void SetContent()
        {
            Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + "/Headers/HeaderAdd.xaml");
        }

Et ça fonctionne parfaitement, mais dès qu'on fait passer une variable de la méthode, plus rien ...

Mais du coup, en effet je ne comprend pas pourquoi cela fonctionnait dans le second cas ...

Ton exemple fonctionne, du coup je vais stocké les Actions dans une List<>...

Par contre, si quelqu'un sait pourquoi ça fonctionnais quand c'était dans la même classe je suis preneur (à cause de la pile qui contenait encore les valeur... bizarre quand même)

Merci

[tomlev]

(à cause de la pile qui contenait encore les valeur... bizarre quand même)

Ca pourrait être un truc comme ça...

Si tu veux une réponse d'expert, tu peux poser la question sur Stack Overflow (en anglais bien sûr). Il y a très souvent des grosses pointures qui viennent répondre aux questions (genre Eric Lippert, Jon Skeet...)

[jmix90]

Une idée en lisant le code :

Dans le deuxième exemple, tu ne passes pas le namespace comme une String mais via une référence "this" et cela doit maintenir en vie ton delegate car il contient une référence vers un objet encore en vie.

Dans le premier exemple, tu passes le namespace en tant que valeur (String) et le delegate n'est peut être pas maintenu en vie.

Si tu passes les paramètres en tant que reference(ref) peut être que cela fonctionnera ?

Bon courage !

[tomlev]

cela doit maintenir en vie ton delegate car il contient une référence vers un objet encore en vie.

Ben non... le fait d'avoir une référence vers un objet en vie n'empêche pas d'être collecté par le GC, c'est dans l'autre sens que ça se passe. Il faut qu'un objet en vie ait une référence vers le delegate pour l'empêcher d'être collecté