Décrivez la mécanique des événements (Events) dans Visual Basic et donnez un exemple de création d'un événement personnalisé. Quels points faut-il prendre en compte lors de la déclaration et de l'inscription ?

Réponse

Dans Visual Basic, les événements (Events) permettent à un objet d'informer d'autres composants de l'application des changements qui se sont produits. Un événement est déclaré avec le mot-clé Event. Il est déclenché à l'aide de la méthode RaiseEvent (VB.NET) ou Raise (VB6), et les composants peuvent s'y inscrire (Handles/WithEvents).

Exemple VB.NET :

Public Class Worker
    Public Event WorkCompleted As EventHandler
    Public Sub DoWork()
        ' ...certain travail
        RaiseEvent WorkCompleted(Me, EventArgs.Empty)
    End Sub
End Class

Public Class Manager
    Private WithEvents w As Worker
    Public Sub New()
        w = New Worker()
    End Sub
    Private Sub w_WorkCompleted(sender As Object, e As EventArgs) Handles w.WorkCompleted
        Console.WriteLine("Travail terminé !")
    End Sub
End Class

Points importants :

• Un événement ne peut être déclenché que dans la même classe où il est déclaré
• Si l'événement a des arguments, leurs types doivent être strictement définis
• WithEvents ne peut être utilisé qu'avec des champs et des propriétés de classe
• En vous inscrivant à un événement, n'oubliez pas de vous désinscrire si nécessaire (par exemple, pour éviter les fuites de mémoire)

Question piège

Peut-on déclarer un événement avec un modificateur d'accès Private et s'y inscrire depuis une autre classe ?

Réponse : Non, le modificateur Private limite la visibilité de l'événement uniquement à la classe où il est déclaré. D'autres classes ne pourront pas le voir, donc ne pourront pas s'y inscrire.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans une grande application, des événements étaient créés avec le modificateur Public, mais n'étaient jamais explicitement désinscrits. Lors d'un long fonctionnement de l'application, cela entraînait des fuites de mémoire, car les gestionnaires faisaient référence à des objets inutiles.

---

Histoire

Lors de la migration de VB6 à VB.NET, le développeur s'attendait à ce que l'événement soit accessible dans tous les modules, mais par défaut, l'événement était Friend. En conséquence, le gestionnaire ne se déclenchait pas, et ce bug n'a été découvert qu'au cours des tests d'intégration.

---

Histoire

Le programmeur s'est trompé dans la signature du délégué d'événement - a échangé sender et e. Aucun message d'erreur n'est apparu (le gestionnaire d'événements n'était tout simplement pas appelé), et la logique métier nécessaire était omise jusqu'à la sortie semi-finale.