← Zurück zur Wissensdatenbank← Vorherige FrageNächste Frage →
ProgrammierungWinForms-Entwickler, VB.NET Schnittstellenprogrammierer

Wie wird die ereignisgesteuerte Interaktion zwischen Formularen und Steuerelementen in Visual Basic WinForms-Projekten realisiert? Beschreiben Sie den Mechanismus zum Abonnieren und Abbestellen von Ereignissen, mögliche Fallen und Möglichkeiten zu deren Vermeidung.

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort

In WinForms werden Ereignisse durch Delegaten (Event) und spezielle syntaktische Konstruktionen von Visual Basic — AddHandler und RemoveHandler — implementiert.

  • Abonnieren eines Ereignisses: erfolgt mit dem Operator AddHandler.
  • Abbestellen eines Ereignisses: erfolgt mit RemoveHandler, dabei ist es wichtig, dass der verwendete Handler exakt übereinstimmt.
  • Steuerelemente können mehrere Abonnenten für ein Ereignis haben.

Beispiel:

AddHandler Button1.Click, AddressOf Button1_Click

Sub Button1_Click(sender As Object, e As EventArgs)
    MessageBox.Show("Knopf gedrückt!")
End Sub

' Zum Abbestellen:
RemoveHandler Button1.Click, AddressOf Button1_Click

Beim Schließen von Fenstern oder Zerstören von Objekten sollte man sich unbedingt von Ereignissen abmelden, um Speicherlecks zu vermeiden — der GC entfernt Objekte nicht, solange es Referenzen durch Delegaten gibt.

Fangfrage

F: Was passiert, wenn man vergisst, RemoveHandler beim Zerstören eines Abonnentenobjekts für ein Ereignis aufzurufen?

A: Wenn ein Objekt für ein Ereignis eines anderen Objekts abonniert ist und nicht abgemeldet wurde (RemoveHandler), kann der Garbage Collector den Speicher für den Abonnenten nicht freigeben, da eine harte Referenz über den Ereignisdelegaten bestehen bleibt. Das führt zu einem Speicherleck.

Geschichte

1. In einer Software zur Bearbeitung von Anträgen meldete sich das Protokollobjekt für Ereignisse aller dynamisch erstellten Formulare an. Nach dem Schließen der Formulare wurde RemoveHandler nicht aufgerufen, was im Laufe der Zeit zu einem Anstieg des Speicherverbrauchs führte — Objekte blieben im Speicher, bis das gesamte Programm geschlossen wurde.

Geschichte

2. In einem Bildungsprojekt wurde vergessen, den Ereignishandler bei der erneuten Öffnung des untergeordneten Formulars abzumelden. Das führte dazu, dass bei jeder Öffnung das Ereignis mehrmals ausgeführt wurde (jedes Mal wurde ein neuer Abonnent hinzugefügt), was zu einem kaskadierenden Dublett von Aktionen und Verwirrung in der Logik der Schnittstelle führte.

Geschichte

3. An industriellen Operator-Panels startete der Inspektor einen automatischen Test, der den Handler für das Timer-Ereignis abonniert. Nach jedem Test wurde das Objekt neu erstellt, aber die Abonnierung wurde nicht wieder aufgehoben, was zu einer allmählichen Verlangsamung führte und die kritische Notwendigkeit von RemoveHandler bei der Nutzung von Ereignissen belegte.