Hi!

Wichtiger Edit: Aufgrund der Diskussion dieses ersten Entwurfs habe ich das Teil neu überarbeitet. Ich finde diese Ur-Version (und die Diskussion dazu) immer noch interessant, und die neuere Version weiter unten hat den Schwerpunkt bisserl anders.
Muß man sich halt überlegen, ob man nur die neuere Version wissen will, oder sich den Thread komplett antun möchte.
[/Wichtiger Edit]

Ich denke mir grade ein Tut zum Thema Events aus, und dachte, vlt. fallen euch noch Verbesserungen ein. Und da dachte ich, man könnte besser erstmal im Vorfeld dazu herum-diskutieren, als dassichs gleich als fixnfertig bei die Tuts einstelle. Also los gehts:

---

Mir fällt gelegentlich auf, das Begriffe im Zusammenhang mit Events falsch verwendet werden, vermutlich weil sie nicht richtig bekannt sind. Auch Galileio-Book kann da nicht helfen - die behandeln das Thema nur unzureichend, und wissen selbst nicht recht Bescheid - zB verkaufen sie den codeseitigen Aufruf einer Ereignis-Methode als Ereignis-Kette, und eine Endlos-Rekursion als Endlos-Ereignis-Kette.

Jut. Was ist also ein Ereignis?
Jedem bekannt: In der Intellisense bekommt man die Ereignisse immer mit sonem kleinen Blitz-Icon angezeigt - sinnigerweise, denn Ereignisse können aus heiterem Himmel auftreten, anders als Methoden, die von irgendwoher aufgerufen werden.

Im Grunde aber sind Ereignisse nix anderes als besondere Variablen, nämlich Delegaten.
Wenn man eine Delegat-Variable mit dem Schlüsselwort "Event" deklariert, wird sie zu einem Event, und das bedeutet: Sie ist fast ReadOnly - man kann ihren Wert nur noch mit genau 3 Anweisungen verändern: AddHandler, RemoveHandler und die Handles-Klausel (eine Art initialisierendes AddHandler). (Und sie bekommt den Blitz-Icon ;)).

Was genau ist ein Delegat?
Delegaten sind Variablen, deren Datentyp nicht Double, Integer oder sonstwas ist, sondern die Signatur einer Methode.
Aha.
Und was bitte ist "Signatur einer Methode"?
So bezeichnet man ihre Aufrufe-Syntax - Beispiel:
Obige Methode erwartet 2 Argumente: Das erste vom Typ Object (kann also alles sein), das zweite vom Typ EventArgs. Die Methode gibt keinen Wert zurück.

nächstes Beispiel:
Diese Methode erwartet zwei Doubles und gibt einen zurück

Diese erwartet eine List(Of String) und einen String - und gibt einen Integer zurück.

Wie kann sowas komplexes - mehrere ArgumentTypen und ggfs. ein Rückgabewert - selbst wieder Datentyp einer Variablen sein?
Jo, is eben so - da gewöhnt man sich dran
Einen Delegaten für obige Function FindIndex() könnte man etwa so deklarieren:
Ists erkennbar, wie Func(Of List(Of String), String, Integer) genau die Signatur von FindIndex wiederspiegelt?
Der letzte TypParameter - Integer - bezeichnet bei Func(Of ...) den Rückgabewert.

Für Subs - Methoden ohne Rückgabewert - muß man halt Action-Delegaten definieren:

Func(Of ...) und Action(Of ...) sind generische Delegat-Typen, mit denen man praktisch jede Signatur spezifizieren kann.

Schön - bleiben 2 Fragen offen: a) was hat man davon? b) was hat das mit Events zu tun?

Zu a): Ein Delegat kann eine Methode aufrufen, wenn deren Signatur passt.

Ein Delegat kann sogar mehrere Methoden (fast) gleichzeitig aufrufen.

Und man kann die Methoden auch wieder entfernen:
Und das ist jetzt wirklich toll, denn hier haben wir ein fabelhaftes Instrument zur Implementation des Observer-Patterns.
Das bedeutet: Ein Objekt versendet Benachrichtigungen, und andere Objekte können diese Nachrichten abonnieren oder auch nicht.
Zum Beispiel ein Button namens Button1 versendet die Click - Nachricht, und mit folgender Methode kann man dieses Ereignis behandeln:

Hoho - da habich euch aber schön an der Nase herum geführt: vonne Ereignisse über Delegaten, Signaturen, Observer-Pattern und wieder zurück zu Ereignissen, wie sie der blutigste Anfänger schon kennt, noch bevor sein "Hallo Welt" - Programm überhaupt das Licht eben dieser erblickt hat ;).
Aber tatsächlich war das gar keine Abschweifung, weil - ich wiederhole: Events sind Delegaten. Sie unterliegen nur zusätzlichen Regeln, nämlich dass sie Readonly sind und dasses statt der wirklich abscheulichen Verknüpfungs-Syntax (das mittm DirectCast(Delegate.Combine(....),...)) super-praktische Schlüsselworte gibt: AddHandler, RemoveHandler, Handles-Klausel (und niemals nich vergesse diese hübsche Blitz-Icone ) .
Und Ereignis-Behandlung ist die einfachste und vollkommenste Implementation des Observer-Patterns, die man sich denken kann - so einfach, dass nur die wenigsten überhaupt wissen, was für einen fabelhaften Pattern sie da grade implementieren

Die Begriffe aber nochmal genau genommen
Also .Click ist das Ereignis, und das ist Member der Button-Klasse. Und Button1_Click() ist kein Event, sondern eine EventHandler-Methode (wenn sie tatsächlich das .Click-Event abonniert).
Beim Button ist .Click fertig eingebaut - da kommt man nicht ran. Aber wir können Handler-Methoden für dieses Event schreiben, oder uns sogar generieren lassen (etwa wenn wir im Form-Designer auf einen Button doppelklicken).

Mal was praktisches: Eine Richtextbox, die nur bestimmte Zeichen zulässt.
Das Problem ist, dasses nicht reicht, Tasten-Ereignisse zu überwachen, denn es kann ja auch per Drag & Drop Text eingeben werden, oder nach Guttenberg (copy & paste ;)).
Also müssen wir das TextChanged behandeln, mit folgender Tücke: Wird beim Auftreten eines unerwünschten Zeichens der Text korrigiert, so löst die Korrektur gleich wieder ein TextChanged-Ereignis aus (das ist nämlich eine EreignisKette - nicht wenn man codeseitig einen EventHandler aufruft).
Eine weitere, noch tückischere Tücke: Das TextChanged ist als Event unzureichend, denn wir wollen auch die Selection wieder herstellen, wie sie war, bevor das böse Zeichen eingegeben wurde. Also nehmen wir das SelectionChanged-Event - dort kann man ebensogut den neuen Text abrufen, und man ist zusätzlich immer über die aktuelle Selection im Bilde (und es gibt ebenso eine Ereigniskette, wenn man innerhalb des SelectionChanged-Events die Selection changed ;)).
Ja, die klugen Dinge über Observer-Pattern, und dass man Events abonnieren kann und wieder abbestellen - das wirkt sich hier sehr segensreich aus - ich glaub, ich muß den Code gar nicht weiter kommentieren:
(die SelStore-Klasse ist klar - ja? Eine Klasse, die die Selection einer Richtextbox speichern und wieder restaurieren kann)

Einzig diese (eigentlich ganz unschuldig und plausibel aussehende) Zeile
wird manchem ein Rätsel bleiben: wie zum Kuckuck kann man in einer Zeile Code alle Zeichen von .Text gegen alle Zeichen des allowed-Strings abgleichen?
Hmm - das wäre ein anderes Tutorial, nämlich zu den Themen Linq, Interfaces, Extensions, Generica, Delegaten (schon wieder!), anonymen Methoden und Type-Inference.
Naja - kurz das mit die Delegaten: .Text.All(predicate As Func(Of Char, Boolean)) erwartet einen "Bedingungs"-Delegaten, den es für jedes Zeichen aufruft, um das Zeichen mit True oder False zu "bewerten" (daher Boolean als Rückgabewert der predicate-Signatur). Nur wenn alle Zeichen des Textes mit True bewertet werden, gibt .All() sinnigerweise auch True zurück. Auf diese Weise drückt .All() aus, ob eine Bedingung für alle Zeichen zutrifft (gewissermaßen ohne die Bedingung selbst zu kennen - listig, nicht?).
Jo, und Function(c) allowed.Contains(c) ist so ein Bedingungs-Delegat (allerdings auch noch als anonyme Methode notiert): Die Bedingung ist, dass ein Zeichen c im allowed-String enthalten ist, und das prüft .All() ab, gegen jedes im Text enthaltene Zeichen.
Naja - für wen das jetzt zu schnell war machts hoffentlich Appetit darauf, VisualBasic.Net 2008 richtig zu lernen, u.U. auch mal dieses Buch zu lesen

Ereignisse selbst schreiben
Ganz anneres Beispiel: Angenommen der WinForms-ColorDialog gefällt uns nicht, und wir wollen ein UserControl, welches alle KnownColors auflistet, sodass man jederzeit eine auswählen kann, ohne einen Extra-Dialog öffnen zu müssen:
Wie kriegen wirs nun hin, dass zB ein Button auf dem Form1 immer die im uclColorSelector angewählte Farbe hat?

Wie mans nicht hinkriegen sollte:

1. Quick & Dirty

   VB.NET-Quellcode

   1. Private Sub ListBox1_SelectedIndexChanged( _
   2. ByVal sender As Object, ByVal e As EventArgs) Handles ListBox1.SelectedIndexChanged
   3. Form1.Button1.BackColor = _Brushes(ListBox1.SelectedIndex).Color
   4. End Sub
   Diesen Leuten muß man vergeben, "denn sie wissen nicht, was sie tun"
   Form1 ist gar kein Objekt, sondern ist eine Klasse, also der Bauplan eines Objektes. Trotzdem geht das, und daran ist Microsoft schuld, dasses die VB-Progger so verblödet, dass diese alsbald nicht mehr zwischen Bauplan und Gebautem unterscheiden können (und die c#-ler können sich über uns lustig machen )
   
   
2. gut gemeint, aber eigentlich nur umständlicher ist folgende "Konsequenz" aus 1):
   "Mach eine Public Property vom Typ Form1 in den ColorSelector, initialisiere die, und dann kann der ColorSelector deren Button1 bunt machen"
   Tja, das wird zu Fehlern im Designer führen, denn wenn man so einen uclColorSelector aufs Form zieht, dann ist die form1-Variable erstmal uninitialisiert, der uclColorSelector will aber gleich den Button bunt machen, aber der ist ja noch gar nicht da.
   

Nein, beide Varianten sind im Grunde Spaghetti-Code, zu enge Kopplung, und verstoßen gegen das Kapselungs-Prinzip, nach dem es nur dem Form zusteht, seine Buttons zu colorieren - nicht iwelchen draufgezogenen UserControls.

Die zu enge Kopplung wird unangenehm, wenn man den ColorSelector mal in eine andere Solution einbauen möchte - das geht nämlich gar nicht: Weil er ist davon abhängig (gekoppelt), dass es ein Form1 gibt, und zwar eines mit einem Button1 drauf. Architektonischer Mist - siehe auch VeryBasics - Kommunikation der Objekte.

Korrekte Lösung - Observer-Pattern
Der ColorSelector soll logisch eine Nachricht verschicken, und wer die erhält, soll selber zusehen, wie er seine Buttons bunt kriegt.(Das <DefaultEvent()> - Attribut veranlasst übrigens den Form-Designer, beim Doppelklick auf meinen uclColorSelector gleich den korrekten EventHandler in den Code-Editor zu generieren - wie man es auch kennt von Button.Click und Konsorten).
Ansonsten haben wir hier genau, was oben versprochen wurde: Eine Public Delegat-Variable - SelectedColorChanged, die mittels des Event-Schlüsselwortes in ein Event verzaubert wurde. Und übrigens das 4. Event-spezifische Schlüsselwort: RaiseEvent. Weil den in ein Event verzauberten Delegaten kann man nun nicht mehr so simpel aufrufen wie weiter oben buttonKlickser(Nothing, EventArgs.Empty), sondern nurnoch mittm RaiseEvent-Schlüsselwort.
Aber war buttonKlickser nicht deklariert As Action(Of Object, EventArgs)? Hier steht jetzt aber As EventHandler!
Ja, weil ist dasselbe
EventHandler ist ein vorgefertigter DelegatTyp, der ebenfalls die Signatur Action(Of Object, EventArgs) spezifiziert.
Früher (vor 2005) hatte man für jeden Delegaten erst noch einen extra Delegat-Typen deklarieren müssen, in dieser Art:Heute kann man fast jede mögliche Signatur mit den generischen Delegat-Typen Action(Of...) und Func(Of...) nach Bedarf modellieren. Aber das Framework ist weiterhin voll von vorgefertigten ungenerischen Delegat-Typen, und im Falle von Events spricht nix dagegen, die auch zu benutzen.

Design-Richtlinie Event-Signatur
Theoretisch kann man für seine Events absolut beliebige Signaturen festlegen - man macht sich damit aber sogleich des Dilettierens verdächtig, weil im Framework ist die folgende Richtlinie ausnahmslos bei allen(!!) Events umgesetzt, und ich habe noch nie erlebt, dass ein Nicht-Dilettant sich unterstanden hätte, von dieser Richtlinie abzuweichen (Ausnahme: EBC - event-driven Architecture - aber das ist wirklich ein anderes Tutorial)
Also: Die Signatur eines Events ist immer Sub EventName(sender As Object, e As EventArgs).
Anhand des senders kann in Handlern, die Events mehrerer Objekte behandeln, der jeweilige Sender identifiziert werden. Ich nutze das gerne zB für Menüs:

Eigene EventArgs
EventArgs ist eine wirklich eigentümliche Klasse, mit überhaupt keinen Properties. Die Klasse kann aber beerbt und mit Properties und allem Möglichen erweitert werden.
Häufige Verwendung findet etwa das CancelEventArgs, mit seiner Property e.Cancel, die man auf True setzen kann, um beispielsweise in einem Form_Closing-EventHandler das Closing zu canceln.
Im Beispiel mittm ColorSelector könnte man es nun praktisch finden, beim Versenden der ColorChanged - Nachricht gleich die neue Color mitzuschicken.
Dazu muß man aber erstmal so ein EventArgs erfinden, mit dem man eine Color auch herumschicken kann:
Und dann folglich:
Dann kommt das im Form so raus:

Vererbungslehre
Ereignisse sind wirklich beschränkte Delegaten: Readonly, man kann sie nicht als Methoden-Argumente weiterreichen - ja man kann sie nicht einmal von außerhalb der Klasse auslösengehtnich.

Nicht einmal ein Erbe von uclColorSelector könnte RaiseEvent in Anschlag bringen.
Diese Einschränkungen sind durchaus sinnvoll, und verhindern, dass Schindluder getrieben wird. Will man eine Event-bestückte Klasse beerben und der abgeleiteten Klasse gestatten, auch das Event auszulösen, muß man halt codetechnisch was dafür tun - sprich: eine OnEvent-Methode bereitstellen. Die gesamte Choose - vonne EventArgs-Deklaration, über die OnEvent-Methode bis zum Auslösen - mag sich dann so darstellen:
Jetzt kann auch ein Erbe das Event raushauen:Beachte auch die Unterscheidung zwischen dem ungenerischen DelegatTypen EventHandler und dem generischen DelegatTypen EventHandler(Of ColorChangedEventArgs)

BenamungsRichtlinie
Obiges ist ein voll ausprogrammiertes Beispiel eines benutzerdefinierten Events, und folgt den MS-Richtlinien, was Benamung und Signaturen betrifft, sowohl die Signatur des Events als auch die der OnEvent-Methode, und auch die zusammenhängende Benamung all dieser Elemente.

In der Praxis muß man nur selten diesen Aufwand treiben. Tatsächlich ist ersteres - das SelectedColorChanged-Event ohne selbstdefinierte EventArgs auch noch flexibler - die SelectedColor-Property braucht man ja eh - und es unterstützt so nebenbei Databinding - wenn man sich an die zusammenhängende Benamung der Property Xy und des XyChanged-Events hält.
Aber das ist auch ein anderes Tutorial

raist10 schrieb:

- Events verweisen nicht auf andere Funktionen
- Events wissen selber nichts von Ihren "Target"
Im Gegensatz dazu muss ein Delegate immer auf eine andere Funktion (oder einem anderen Delegaten) verweisen und kennt damit diese.

Klar verweist ein Event auf eine andere Funktion. Man muß sie dem Event halt zuweisen - in VB mittels AddHandler. Ein Button.Click - Event verweist auf mw. Button1_Click(sender As Object, e As EventArgs).
In c# wird die Identität von Event und Delegat noch deutlicher - da gibt es überhaupt keine syntaktischen Unterschiede. Allein durch das Schlüsselwort "event" werden die spezifischen Zugriffsbeschränkungen definiert, sodaß unten die auskommentierte Zeile failt
Die VB-Schlüsselworte AddHandler und RemoveHandler sind nur syntaktischer Zucker, über den auf die Delegate.Combine/Remove - Methoden zugegriffen wird.
RaiseEvent hat noch etwas zusätzliches eingebaut, damit ein unabonniertes Event nicht zum Fehler führt - was dahintersteckt kann man an c# ziemlich klar erkennen - die müssen das nämlich selbst coden:

raist10 schrieb:

Du weisst nie einem Event eine Funktion zu, sondern Du weisst einer Funktion zu auf ein Event zu reagieren. Das Event selber hat nach wie vor keinerlei Ahnung davon von wem es abgehört wird.

nein, das ist definitiv falsch.

Dem Event wird der EventHandler zugewiesen, nicht dem EventHandler das Event - AddHandler addet einen EventHandler, sonst hiesse es AddEvent.
Ein EventHandler ist eine Methode, die aufgerufen wird - so etwas hat gar keinen Status, in dem es etwa zugewiesene Events speichern könnte.

Auch hier zeigt c# wieder klarer, was abgeht:
Das Event MyTestEvent verfügt über eine Methode GetInvocationList - kann also seine Aufrufeliste zur Verfügung stellen - und GetInvocationList() findet sich im ObjectBrowser als Member der abstrakten (MustInherit) Klasse System.Delegate.

Daran gefällt mir auch, zu sehen, dass das auch nur mit Wasser gekocht ist: "Lauschen" ist eigentlich etwas, was ein Computer gar nicht kann - es muß immer eine Quelle von Aktivität geben - bei Events eben den Event-Sender.
So sieht man, dass hinter der ereignisorientierten Programmierung auch nix als die gute alte prozedurale Logik steckt: Der Sender ruft brav einen Abonnenten nach dem andern auf - "Ereignis aus heiterem Himmel" - in Wirklichkeit gibts das nicht.

picoflop schrieb:

btw: Hat eigentlich schon jemand den versteckten automatischen Delegaten erwähnt?

Wenn
public Event Foo()

dann existiert auch der Delegate
FooEvent

Jo - stimmt. Und belegt ein stückweit meine Behauptung, dass Events Delegaten sind.
Nungut, was man da als Event zu sehen bekommt ist eine art Wrapper-Property, die dann die zulässigen Operationen, die hinter AddHandler, RemoveHandler, Handles-Klausel und RaiseEvent stehen, an den Delegaten durchreicht.

Jo, über picoFlops Hinweis habich nochma gehirnt, und glaube, folgende Aussage zur Beziehung Event <-> Delegat machen zu können:
Ein (nicht custom-) Event kapselt einen verborgenen Delegaten in ebenfalls verborgene Zugriffs-Methoden, die sich nämlich hinter den Schlüsselworten AddHandler, RemoveHandler, WithEvents, Handles und RaiseEvent verbergen.
Diese Schlüsselworte vereinfachen das abonnieren und abbestellen nach dem Observer-Pattern und schützen den Delegaten vor allzu kreativem Umgang (etwa auf Nothing setzen, überschreiben oder sowas)
CodeSample dazu:gecodet ist ein ganz klassisches Event, inklusive Abonnement. Aber in RaiseTwoTimes() wird zusätzlich zur normalen Auslösung per RaiseEvent das Event nochmal quasi "als Hack" ausgelöst, indem nämlich der verborgene Delegat direkt aufgerufen wird.


Auch eine WithEvents-Variable stellt eine verborgene Property dar - ungefähr die folgende:
Diese verborgene Property ist ziemlich praktisch: Indem man eine Withevents-Variable auf Nothing setzt, löscht man alle Abonnements aller ihrer Events, und indem man ihr eine Instanz zuweist, stöpselt man gleich alle per Handles spezifizierten Methoden an.
Das kann man überprüfen, indem man ein Custom-Event proggt, und einen Haltpunkt auf die Custom AddHandler-Methode setzt.
Da eine WithEvents-Variable in Wirklichkeit eine verborgene Property ist, mit Setter und Getter, kann man auch keine Readonly WithEvent - Variablen deklarieren - schomal aufgefallen?

Ja, da mussich nochmal weiter-hirnen, wie und was davon ich ins Tut reinmach. Von praktischem Belang ist eigentlich nur, dass man lernt, Event und Handler ausnander zu halten, und was Signaturen sind (und die fabelhaften Action / Func(Of ...) ), und dass hinter Events dieselben Delegaten stecken, die einem auch noch an so einigen anneren Ecken übern Weg laufen (Threading, Linq, anonyme Methoden und einiges mit Interfaces)

also ich wollte mich bei euch noch für die fabelhafte mitarbeit zu bedanken

Ich denk, ich werd den ganzen Salmon nochmal neu anfangen, und diesmal nicht mit "Event = Delegat" einsteigen, sondern das Zeugs vlt. aus einem Einstieg ala "Event = Observer-Pattern" heraus entwickeln.

Weil was es ist ist ja weniger wichtig als wozu.