En Visual Basic (VB.NET), pour créer des contrôles de manière dynamique, on crée une instance de la classe nécessaire et on l'ajoute à la collection Controls. Pour traiter les événements des contrôles créés dynamiquement en VB.NET, on utilise des délégués et l'instruction AddHandler :
Exemple (VB.NET) :
Dim btn As New Button() btn.Text = "Cliquez-moi !" btn.Location = New Point(40, 40) Me.Controls.Add(btn) AddHandler btn.Click, AddressOf Button_Click Private Sub Button_Click(sender As Object, e As EventArgs) MessageBox.Show("Bouton créé dynamiquement cliqué.") End Sub
Dans le VB6 classique, la création dynamique et le traitement des événements pour les contrôles sont possibles uniquement via des tableaux de contrôles (Control Arrays), où les indices distinguent les éléments individuels :
Exemple (VB6) :
' Sur le formulaire, il doit y avoir un élément CommandButton avec Index = 0 Load Command1(1) Command1(1).Visible = True Private Sub Command1_Click(Index As Integer) MsgBox "Le bouton avec l'indice " & Index & " a été cliqué !" End Sub
Il convient de se rappeler qu'en VB.NET, il n'existe pas de concept de tableaux de contrôles comme en VB6 — le traitement des événements pour les contrôles créés dynamiquement est assuré uniquement par le mécanisme des délégués et AddHandler / RemoveHandler.
Question : "Que se passe-t-il si l'on oublie d'appeler RemoveHandler pour les événements d'un contrôle créé dynamiquement lors de sa destruction ? Quelles peuvent en être les conséquences ?"
Réponse : Si l'on oublie d'appeler RemoveHandler avant de supprimer le contrôle, la référence au gestionnaire restera en mémoire, ce qui entraînera une fuite de mémoire (memory leak) et parfois, une tentative d'accès à un objet ou un formulaire déjà détruit, ce qui provoquera une exception.
Exemple :
' RemoveHandler oublié : ' AddHandler btn.Click, AddressOf SomeHandler ' Controls.Remove(btn) ' btn n'existe plus, mais le gestionnaire reste
Histoire
Dans un système de facturation pour terminaux de paiement, des boutons dynamiques étaient créés sur le panneau pour les opérations de paiement. Après la fermeture de la fenêtre, les gestionnaires d'événements restants perturbaient la collecte des ordures (Garbage Collection). Pendant une semaine, l'application provoquait des fuites de mémoire, entraînant des pannes de serveurs et la nécessité de redémarrer manuellement le processus pendant les opérations nocturnes.
Histoire
Dans un projet de visualisation médicale sous WinForms, pour générer un grand nombre de "prévisualisations d'images", des PictureBox étaient créés et détruits. Le développeur ne supprimait pas les gestionnaires d'événements. Après 20-30 chargements, l'application commençait à ralentir : il s'est avéré que des milliers de gestionnaires cachés continuaient à subsister, bloquant la libération des ressources.
Histoire
Dans une des applications éducatives pour enfants, des boutons de quiz étaient formés dynamiquement et, après la fin du jeu, supprimés du formulaire, mais les événements n'étaient pas désinscrits via RemoveHandler. À cause de cela, au début d'un nouveau jeu, des déclenchements "fantômes" du code de vérification se produisaient, entraînant des pop-ups obsolètes, des bogues de points et une confusion générale.