ProgrammationDéveloppeur WinForms, programmeur d'interfaces VB.NET

Comment l'interaction orientée événements entre les formulaires et les contrôles est-elle mise en œuvre dans les projets WinForms en Visual Basic ? Décrivez le mécanisme d'abonnement et de désabonnement aux événements, les pièges possibles et les moyens de les éviter.

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse

Dans WinForms, les événements sont mis en œuvre par le biais de délégués (Event) et de constructions syntaxiques spéciales de Visual Basic : AddHandler et RemoveHandler.

  • Abonnement à un événement : est effectué par l'opérateur AddHandler.
  • Désabonnement d'un événement : est effectué avec RemoveHandler, il est important de toujours correspondre exactement à l'implémentation du gestionnaire ciblé.
  • Les contrôles peuvent avoir plusieurs abonnés à un même événement.

Exemple :

AddHandler Button1.Click, AddressOf Button1_Click Sub Button1_Click(sender As Object, e As EventArgs) MessageBox.Show("Bouton pressé !") End Sub ' Pour désabonner : RemoveHandler Button1.Click, AddressOf Button1_Click

Lors de la fermeture de fenêtres ou de la destruction d'objets, il est impératif de se désabonner des événements afin de prévenir les fuites de mémoire — le GC ne supprime pas les objets tant que des références aux délégués existent.

Question piège

Q : Que se passe-t-il si l'on oublie d'appeler RemoveHandler lors de la destruction de l'objet abonné à l'événement ?

R : Si l'objet est abonné à l'événement d'un autre objet et n'a pas été désabonné (RemoveHandler), alors le ramasse-miettes ne pourra pas libérer la mémoire occupée par l'abonné, car une référence forte sera maintenue à travers le délégué de l'événement. Cela entraînera une fuite de mémoire.


Histoire

1. Dans un logiciel de gestion des demandes, l'objet journal s'abonnissait aux événements de tous les formulaires créés dynamiquement. Après la fermeture des formulaires, RemoveHandler n'était pas appelé, ce qui a entraîné une augmentation de l'utilisation de la mémoire au fil du temps — les objets restaient en mémoire jusqu'à la fermeture de l'ensemble du programme.


Histoire

2. Dans un projet éducatif, ils ont oublié de désabonner le gestionnaire d'événements lors de la réouverture d'un formulaire enfant. En conséquence, à chaque ouverture, l'événement se déclenchait plusieurs fois (un nouvel abonné était ajouté à chaque fois), ce qui entraînait une cascade d'actions dupliquées et de la confusion dans la logique de l'interface.


Histoire

**3. Sur les panneaux industriels, l'opérateur inspecteur a lancé des tests automatisés qui abonnaient le gestionnaire à l'événement du minuteur. Après chaque test, l'objet était recréé, mais l'abonnement n'était pas retiré, ce qui entraînait un ralentissement progressif, prouvant l'importance critique de RemoveHandler lors de l'utilisation des événements.