Discussion :

[DaMo`]

J'ai malheureusement pas la chance d'avoir un Senior près de moi j'ai donc quelques questions qui me traverse l'esprit j'espère trouver de l'aide ici,

1) Pour la gestion d'événement sur un custom control, disant que je dois manipuler l'événement KeyDown, quelle est la meilleur pratique s'abonner et se désabonner à cette event (+= et -= this.KeyDown) ou faire un override de OnKeydown) ?

2) Justement pour le désabonnement des événements faut-il implémenter IDisposable et se débarasser des abonnements la dedans ou par exemple dans l'événement Unloaded du control tous désabonner ? (d'ailleurs si quelqu'un sait pourquoi l'événement Unloaded est "Raised" a la création aussi)

3) Autre problème je suis en train de créer un Scheduler en faite, j'ai un control Event qui est en faite le visuel d'un événement dans le scheduler, ce control Event a une propriété Data du type EventData qui contient toute la partie donnée d'un événement et qui implémente INotifyPropertyChanged.

EventData contient plusieurs propriétés dans un premiers temps quelle est le moyen le plus propre de m'abonner au changement de ses propriétés dans Event ?

EventData contient aussi une propriété un peu plus complexe qu'on va appeler "Objet" qui a elle même des propriétés et qui implémente INotifyPropertyChanged, la encore quelle est le meilleur moyen d'informer Event d'une modification d'une propriété de "Objet" donc :

Event -> EventData -> Objet -> Property1

j'aimerais que Event soit notifié du changement de Property1

Je sais pas si c'est clair ce que je dis n'hésiter pas à le dire si sa ne l'est pas

Merci d'avance

[Samuel Blanchard]

1) Pour la gestion d'événement sur un custom control, disant que je dois manipuler l'événement KeyDown, quelle est la meilleur pratique s'abonner et se désabonner à cette event (+= et -= this.KeyDown) ou faire un override de OnKeydown) ?

D'une manière générale, un override de OnKeyDown est plus simple a utiliser car tu n'as pas a te soucier du désabonnement de l'evenement.

2) Justement pour le désabonnement des événements faut-il implémenter IDisposable et se débarasser des abonnements la dedans ou par exemple dans l'événement Unloaded du control tous désabonner ?

Oui tu peux faire comme ça. Le problème n'est pas vraiment sur l' abonnement en lui même mais sur le moment ou il est effectué. En effet, un évenement auquel on s'est abonné qui ne se désabonne pas ne pourra être nettoyé par le GarbageCollector (MemoryLeaks). Dans une boucle, tu vois le problème...
Si tu restes sur un abonnement dans le Constructeur et Dispose tu n'auras jamais de problème.

http://www.simonferquel.net/blog/arc...moryleaks.aspx

(d'ailleurs si quelqu'un sait pourquoi l'événement Unloaded est "Raised" a la création aussi)

Je ne le savais pas et je ne m'en suis jamais servi.

3) Autre problème je suis en train de créer un Scheduler en faite, j'ai un control Event qui est en faite le visuel d'un événement dans le scheduler, ce control Event a une propriété Data du type EventData qui contient toute la partie donnée d'un événement et qui implémente INotifyPropertyChanged.
EventData contient plusieurs propriétés dans un premiers temps quelle est le moyen le plus propre de m'abonner au changement de ses propriétés dans Event ?

En faisant du Binding sur EventData, si j'ai bien compris.

EventData contient aussi une propriété un peu plus complexe qu'on va appeler "Objet" qui a elle même des propriétés et qui implémente INotifyPropertyChanged, la encore quelle est le meilleur moyen d'informer Event d'une modification d'une propriété de "Objet" donc :

Event -> EventData -> Objet -> Property1

j'aimerais que Event soit notifié du changement de Property1

En faisant du Binding de EventData.Objet.Property1

[DaMo`]

D'une manière générale, un override de OnKeyDown est plus simple a utiliser car tu n'as pas a te soucier du désabonnement de l'evenement.

Oki cool .

Oui tu peux faire comme ça. Le problème n'est pas vraiment sur l' abonnement en lui même mais sur le moment ou il est effectué. En effet, un évenement auquel on s'est abonné qui ne se désabonne pas ne pourra être nettoyé par le GarbageCollector (MemoryLeaks). Dans une boucle, tu vois le problème...
Si tu restes sur un abonnement dans le Constructeur et Dispose tu n'auras jamais de problème.

http://www.simonferquel.net/blog/arc...moryleaks.aspx

Oki, est ce que tu aurais un exemple simple d'implémentation ou y'a juste un abonnement dans le constructeur et le désabonnement avec l'interface Idisposable ( en faite j'ai peur de faire une bêtise )

En faisant du Binding sur EventData, si j'ai bien compris.
En faisant du Binding de EventData.Objet.Property1

Oui avec le visuelle de Event, mais le truc est que j'ai besoin d'une notification dans le code behind de Event et pas dans la partie Visuelle, j'aurai besoin d'être notifié au niveau de Event pour pouvoir faire quelques logiques

Je te remercie pour toutes tes réponses

[Samuel Blanchard]

Oki, est ce que tu aurais un exemple simple d'implémentation ou y'a juste un abonnement dans le constructeur et le désabonnement avec l'interface Idisposable

Le code ci-dessous devrait fonctionner :

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
 
public class MonUserControl : UserControl, IDisposable
 
   // constructeur
 
   MonUserControl()
   {
        // abonnement ici
   }
 
    // destructeur
 
   ~MonUserControl()
   {
        this.Dispose();
   }
 
    #region IDisposable Members
 
    bool isDisposed = false;
 
    public void Dispose()
    {
        if (this.isDisposed == false)
        {
            this.isDisposed = true;
            // desabonnements ici
        }
    }
 
    #endregion
}

Oui avec le visuelle de Event, mais le truc est que j'ai besoin d'une notification dans le code behind de Event et pas dans la partie Visuelle, j'aurai besoin d'être notifié au niveau de Event pour pouvoir faire quelques logiques

Tu peux t'abonner à l'evenement PropertyChanged de EventData coté CodeBehind.

[Samuel Blanchard]

Au sujet du IDisposable du UserControl, je ne suis pas sur que son implémentation que cela soit indispensable tant que l'evenement est utilisé en interne. Je veux dire lorsque l'on dispose un UserControl par exemple dont l'evenement pointe vers une méthode de celui-ci (et donc déjà nettoyée), il ne devrait pas y avoir de MemoryLeaks (cas du Loaded effectuer dans le constructeur) mais si le loaded pointe vers une méthode externe alors la on est bien dans un de ces cas.

Je ne suis pas un pro de ces problèmes de MemoryLeaks, donc si quelqu'un veut rajouter qqchose sur le sujet ?

[DaMo`]

Je veux dire lorsque l'on dispose un UserControl par exemple dont l'evenement pointe vers une méthode de celui-ci (et donc déjà nettoyée), il ne devrait pas y avoir de MemoryLeaks

Je ne suis pas un pro de ces problèmes de MemoryLeaks, donc si quelqu'un veut rajouter qqchose sur le sujet ?

Disant que j'ai des rectangle dans mon custom control et que je m'abonne a des événements sur ces mêmes rectangles est ce qu'il faut cleaner les abonnements ? Je suis un peu perdu...

Autre question, si j'ai bien compris le destructeur est appelé par le GC à un moment ou à un autre sans réelle moyen de savoir quand, mais comment être sur qu'il est appelé ou tout au moins libère les bonnes ressources.

[Samuel Blanchard]

Disant que j'ai des rectangle dans mon custom control et que je m'abonne a des événements sur ces mêmes rectangles est ce qu'il faut cleaner les abonnements ? Je suis un peu perdu...

C'est une bonne pratique lorsque l'on s'abonne à un évenement de se désabonner de celui-ci lorsque l'on ne l'utilise plus.

Un memoryLeaks apparait quand l'abonnement d'un objet pointe vers une methode d'un objet qui n'est pas libérée. Ainsi, si ton rectangle est abonné à une methode existant sur son parent, le rectangle ne sera pas libéré tant que le parent (et donc sa méthode) ne sera pas libéré. Si tu as plein de rectangle tu as plein de MemoryLeak.

Autre question, si j'ai bien compris le destructeur est appelé par le GC à un moment ou à un autre sans réelle moyen de savoir quand, mais comment être sur qu'il est appelé ou tout au moins libère les bonnes ressources.

Mets un point d'arrêt sur ton destructeur, lance ton appli puis quitte le navigateur. tu dois rentrer dans le destructeur au moment ou tu quittes l'appli.

[Samuel Blanchard]

Cette article est intéressant et simple d'accès :

http://www.simonferquel.net/blog/arc...moryleaks.aspx