Discussion :

[lasrevinu]

Bonjour à tous,
je voudrais afficher sur un Label (de mon window form) la date et l'heure qui seraient actualisés à chaque seconde,

voici mon code:

Code :

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

1
2
3
4
5
6
private void label6_Click(object sender, EventArgs e)
        {
            DateTime date1 = DateTime.Now;
            label6.Text = date1.ToString();
 
        } date1.ToString();

avec cela, c'est en cliquant sur le label6 que ma date et heure sont actualisé.
merci d'avance

[sisqo60]

Bonsoir
voila comment faut que tu fasses :

Code :

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

1
2
3
4
5
 
System.Windows.Forms.Timer monTimer = new System.Windows.Forms.Timer();
            monTimer.Tick += (sender, eventArgs) => { label6.Text = DateTime.Now.ToString(); };
            monTimer.Interval = 100;
            monTimer.Start();

tu mets ce code après le InitializeComponents et le tour est joué...

[tomlev]

Bonsoir
voila comment faut que tu fasses :

Code :

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

1
2
3
4
5
 
System.Windows.Forms.Timer monTimer = new System.Windows.Forms.Timer();
            monTimer.Tick += (sender, eventArgs) => { label6.Text = DateTime.Now.ToString(); };
            monTimer.Interval = 100;
            monTimer.Start();

tu mets ce code après le InitializeComponents et le tour est joué...

Effectivement ça devrait le faire... sauf un petit détail
Il faut absolument déclarer le timer comme un champ de la classe : si tu le déclares juste en variable locale et que tu ne conserves aucune référence dessus, il finira par être ramassé par le garbage collector et ne fonctionnera plus...

Le plus simple est encore de le créer via le designer, qui fait ça proprement

[Pol63]

en étant abonné à l'évent sur une instance non collectable le GC peut ramasser le timer ????
(bien qu'ici c'est un type d'abonnement qu'on a pas en vb, une méthode anonyme je suppose)

[tomlev]

en étant abonné à l'évent sur une instance non collectable le GC peut ramasser le timer ????
(bien qu'ici c'est un type d'abonnement qu'on a pas en vb, une méthode anonyme je suppose)

L'abonnement à l'évènement fait que le timer a une référence sur l'objet qui contient la méthode anonyme, mais personne n'a de référence sur le timer... donc dès qu'il sort du scope de la méthode, il n'est plus accessible et est donc collectable

[Pol63]

pourtant il est dit que les abonnements d'évènements peuvent faire des fuites dues à des objets non collectables
et je viens de tester, avec un gc.collect, le timer tourne toujours (par contre méthode pas anonyme)

[tomlev]

pourtant il est dit que les abonnements d'évènements peuvent faire des fuites dues à des objets non collectables

Oui, mais dans "l'autre sens"... l'objet qui expose l'évènement (appelons cet objet E) garde une référence vers les handlers, donc l'objet auquel appartient le handler n'est pas collectable, sauf si E est collectable. Dans le cas présent, la form est abonnée à l'évènement Tick du Timer, donc le Timer a une référence vers la Form, et personne n'a de référence vers le Timer

Un cas fréquent de fuite mémoire est quand tu abonnes une méthode d'instance à un évènement statique : dans ce cas la référence à l'objet qui contient la méthode est toujours conservée par l'évènement statique (sauf désabonnement explicite), ce qui peut causer des fuites si on n'y fait pas attention

[Guulh]

D'ailleurs, tiens, à ce sujet : y'a des bonnes pratiques ? Parce que comme tu dis, l'émetteur de l'event se retrouve avec une référence vers chacun de ses clients ; ce qui signifierait que le fait d'être abonné est une "ressource", qu'il faudrait prendre en compte via le pattern Dispose, par exemple.

Typiquement, des classes d'UI sont abonnées à des propertychanged d'objets métier. Faudrait vérifier si à la Disposition d'une fenêtre, et donc de tous ses contrôles fils, les bindings sont coupés.

[sisqo60]

bonjour
Désolé de vous contredire, mais dans ce cas là, pour la méthode anonyme il génère une méthode private dans la classe et ce réferencement fort empêche le Garbage Collector de passer pour ramasser notre joli timer. Mais sans cette méthode anonyme vous auriez complètement raison...

[tomlev]

bonjour
Désolé de vous contredire, mais dans ce cas là, pour la méthode anonyme il génère une méthode private dans la classe et ce réferencement fort empêche le Garbage Collector de passer pour ramasser notre joli timer. Mais sans cette méthode anonyme vous auriez complètement raison...

non, je persiste... le fait d'abonner cette méthode anonyme à l'évènement Tick fait que le timer garde une référence sur la fenêtre, et non le contraire. Il ne reste aucune référence vers le timer, il peut donc être collecté n'importe quand. D'ailleurs le fait que ce soit une méthode anonyme n'y change change rien, le résultat serait le même avec une méthode membre

[Guulh]

bonjour
Désolé de vous contredire, mais dans ce cas là, pour la méthode anonyme il génère une méthode private dans la classe et ce réferencement fort empêche le Garbage Collector de passer pour ramasser notre joli timer. Mais sans cette méthode anonyme vous auriez complètement raison...

Je crois bien que tomlev a raison Personne n'a de lien vers le timer : c'est le timer qui a lien vers le "possesseur" de la méthode, à savoir la form.
Si a possède un référence vers b, alors le GC ne peut collecter b sans collecter a. Par contre, il peut collecter a sans collecter b.

[lasrevinu]

Le problème est résolu,
Le code marche et l'affichage est stable,
je vous remercie tous de tout coeur.

[tomlev]

Bon, j'ai fait un petit test, et comme ça marchait pas comme je croyais, j'ai regardé le code du Timer avec Reflector... et il semblerait qu'on ait tous raison et tort à la fois

En fait, mon raisonnement sur les références liées aux évènements est correct... mais le timer n'est pas collecté tant qu'il est actif.

L'explication se situe dans le code du set de la propriété Enabled :

Code :

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

1
2
3
...
this.timerRoot = GCHandle.Alloc(this);
...

Quand on l'active, le Timer s'alloue un GCHandle, ce qui empêche qu'il soit collecté...

Donc, avec le code de sisqo60, il n'y a effectivement pas de risque que le timer soit collecté prématurément, mais c'est uniquement lié à l'implémentation spécifique du timer. D'une manière générale, il faut toujours garder quelque part une référence vers l'objet si on ne veut pas qu'il soit collecté

[Pol63]

merci bien pour cette investigation