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.

Event-orientiertes versus prozedurales Denken
Ja, mitte Events ist das eine ganze Denkweise. Gelegentlich finden sich Fragen in Foren, wie:
"ich habe 5 Items, und möchte jede Sekunde eins davon meiner Listbox zufügen - wie muss ich die For-Schleife machen?"
Der Fehler liegt hier im prozeduralen Denken: Klar, der Computer arbeitet grundsätzlich prozedural, und eine For-Schleife hat in NullkommaNixMinusEins die 5 Items eingefügt - aber jeweils die Sekunde warten - grad das kannernich.
Natürlich kann man ihn ausbremsen, mit Thread.Sleep(1000) - aber das versetzt die ganze App ins Koma - da wird dann auch die Anzeige der neuen Items nicht mehr geupdated.
Nein - man musses ereignisorientiert angehen: Jede Sekunde ein Ereignis - füge ein Item zu, und weitermachen, mit - nichts.
Das ist nämlich, was ein Computer am meisten macht: Nichts.
Warten, dass sich ein Ereignis ereignet. Das ist, wie eine Anwendung interaktiv ist, und endlos Interaktions-Möglichkeiten anbietet: Grundsätzlich nichts tun - aber wenn der User Button1 klickst, oder in Textbox1 schreibt, oder, oder, oder... - dann tut sie schnell mal was, und dann wieder nichts.
Diese beiden Denkweisen sind übrigens nicht verfeindet, sondern Player desselben Teams: Die Grundstruktur ist ereignisorientiert und im Wartezustand. Ereignet sich ein Ereignis, wird dieses schnellstmöglich prozedural abgearbeit, denn der Prozessor will seine Ruhe haben damit die App gleich wieder bereitsteht für User-Interaktionen.

Begrifflichkeiten
Bei einem Event gibt es immer einen Sender, der das Event versendet, und keinen, einen oder mehrere Empfänger, die es abonnieren - (oder auch wieder abbestellen).
Der Sender "verschickt" sein Event, indem er alle Methoden aufruft, die sein Event abonnieren. Diese Methoden heißen Handler-Methoden, EventHandler oder einfach Handler. Mit diesen Methoden behandelt der Empfänger das abonnierte Event.
Ich stelle das deshalb so deutlich heraus, weil viele Leuts haben keine klare Unterscheidung von Event (ein Aufruf-Mechanismus im Sender) und EventHandler (eine Methode im Empfänger)
Dieses Muster: "mehrere Empfänger können Nachrichten eines Senders abonnieren oder abbestellen" heißt in der Informatik: Observer-Pattern

Der erste Kontakt
Die Begriffs-Verwirrung rührt sicher auch daher, dass man als Anfänger über lange Zeit Events ausschließlich von der Handler-Seite her kennt. Das hier:
ist vmtl. der erste Code, den ein Anfänger schreibt - (tatsächlich schreibters ja nicht selbst, sondern lässtes sich generieren, etwa, indem er im Form-Designer einen Button doppelklickst).

Erst relativ spät kommt man in Verlegenheit, auch die Sender-Seite implementieren zu müssen. Jo, und wenn man gar nicht weiß, dass das ühaupt geht, kommts u.U. zu ziemlich schlimmen Frickel-Lösungen - ich komme noch dazu.

Observer-Pattern: Handles-Klausel versus AddHandler / RemoveHandler
Was uns der Designer hingeneriert, ist überaus praktisch und zuverlässig, aber es verschleiert ein bischen den dahinterstehenden Observer-Pattern: Denn im Hintergrund erstellt die Handles-Klausel eine unsichtbare Property, in deren Setter mit AddHandler/RemoveHandler das angegebene Event registriert/deregistriert wird.
Bei dynamisch erzeugten Objekten geht das statische "Handles" schon rein syntaktisch nicht.

Ereigniskette
Eine Ereigniskette hat man am Hals, wenn der EventHandler Code ausführt, welcher das Ereignis selbst wieder auslöst. So eine Ereigniskette unterhält uns mit allerlei originellem Verhalten: miese Performance, erstaunliche Berechnungen "Nanu - wo issn der Wert her??", Geflacker, Rumhopsen von Controls, und im Extremfall Endlos-Ereigniskette - hängt die App.
Wie gesagt: Hier kann man das Ereignis einfach abbestellen, solange man den sensiblen Code ausführt.

Beispiel zu AddHandler / RemoveHandler: Richtextbox, die nur bestimmte Zeichen zulassen soll
Wann immer ein unerlaubtes Zeichen sich anfindet, soll der Text auf den vorherigen Zustand zurückgesetzt werden, inklusive der Selection. Deshalb muß die Überprüfung im _SelectionChanged-EventHandler stattfinden, und ggfs. müssen Text und Selection restauriert werden (was bei der Selection eine Ereigniskette verursachen würde):(die SelStore-Klasse ist klar? Damit kann man die Selection einer Richtextbox speichern und wieder restaurieren)

Schwierigkeiten mit der Signatur
Obiges Beispiel sieht schmissig aus, aber wenn man selbst mal versucht, ein Ereignis mit AddHandler zu abonnieren, baut man schnell folgenden Fehler, nachdem man die HandlerMethode hingeschreiben hat, und will abonnieren:

WtF...?
Ja, ist schon absolut genau und richtig, wasser sagt - blos: wovon redet er? Was ist eine Signatur, was ein Delegat, und wieso kommter jetzt mit diesem EventHandler-Dingsbums an?
Also langsam: Wir wollen ja ein Event abonnieren. Das heißt, unsere Handler-Methode soll aufgerufen werden durch den Event-Mechanismus. Aber das Event kann ja nicht jede x-beliebige Methode aufrufen, sondern nur eine, die auch passt.
Logisch: Eine Methode, die einen Integer erwartet, kann nicht ein Event abonnieren, welches einen String verschickt. (Jaja - für Option Strict Off - Progger ist das nicht logisch - aber die brauchen noch grundlegendere Tutorials ;))
Also Anzahl, Reihenfolge und Datentyp von Argumenten und Rückgabetyp - das ist die Signatur einer Methode.
Der Verschick-Mechanismus des Events benutzt einen Delegaten: Das ist eine Variable, deren Datentyp eben eine Signatur ist, und der man Methoden zufügen kann (so verrückt das auch klingt). Mehrere sogar (noch verrückter), und wenn man diesen Delegaten dann aufruft, werden dadurch alle geaddeten Methoden aufgerufen. (In C hat man Function-Pointer für sowas - aber die sind total unsicher, weil können überall hinzeigen, und der Absturz bleibt nur aus, wenn sie tatsächlich auf eine passende Funktions-Addresse zeigen.)
Jdfs, was uns der Compiler hier haarklein (und unverständlich) erklärt, ist, dass der Datentyp des Delegaten, der das Event verschicken will, nicht zur Signatur der Methode passt, die es abonnieren soll.
Er führt uns sogar nochmal die Signatur unserer eigenen Handler-Methode vor Augen, und stellt sie der Definition des Event-Delegaten gegenüber - gugge nochma:

So, dassis jetzt geklärt, und wie mans richtig macht, ist ja weiter oben gezeigt.

Zur Übung bringe ich nochn paar Beispiele von Signaturen - weil dassis fast ebenso wichtig zu verstehen, wie das Konzept der Datentypen überhaupt:bereits gesagt: erwartet ein Object und ein EventArgs, kein Rückgabewert - nächstes Beispiel:
Diese Methode erwartet zwei Doubles und gibt einen zurück

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

Abschweifung: die generischen Delegaten Action(Of...) und Func(Of...) für jede Signatur
Im Framework sind tausende verschiedener Delegaten definiert - eigentlich ganz überflüssigerweise, denn seit Einführung der Generika kann man (fast) jede Signatur als Action oder Func definieren: Der obige EventHandler Button1_Click etwa wäre ebensogut als Action(Of Object, EventArgs) definiert, Multiplicate ist eine Func(Of Double, Double, Double) und FindIndex eine Func(Of List(Of String), String, Integer).
Ist das Prinzip klar geworden? Bei Action(Of...) definieren die TypParameter die Methoden-Argument-Typen von Subs, bei Func(Of...) dito, nur gilt der letzte TypParameter für den Rückgabewert.
So, jetzt wisst ihr das auch, und dass man Signaturen am kürzesten als Action oder Func ausdrückt.

Noch abgeschweifter
Ihr habt euch bei der Betrachtung dieser Zeile sicher gefragt:
"WtF! wie kann man in einer Code-Zeile alle Zeichen von .Text gegen alle Zeichen des allowed-Strings abgleichen?" - habt ihr nicht gefragt? - egal - erklär ich trotzdem, weil das geht mit Func und Signaturen:
Also im CodeEditor per Rechtsklick auf "All" - "zu Definition gehen" - zeigt uns die .All()-Signatur im ObjectBrowser:
.Text.All(predicate As Func(Of Char, Boolean)) - als Argument erwartet wird also ein "Bedingungs"-Delegat ("predicate"), der für jedes Zeichen im Text aufgerufen wird, nämlich, um das Zeichen mit True oder False zu "bewerten" (daher Boolean als Rückgabewert der predicate-Func).
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, und zwar ohne die Bedingung zu kennen - die kann übergeben werden - als Parameter!
Jo, und Function(c) allowed.Contains(c) ist so ein Bedingungs-Delegat-Parameter (notiert als anonyme Methode): Die Bedingung für ein Zeichen c ist True, wenn es im allowed-String enthalten ist.
Und dieses prüft .All() gegen jedes im Text enthaltene Zeichen ab.
Naja - für wen das jetzt zu schnell war weckts vlt. Interesse, VB2008 richtig zu lernen, u.U. sogar dieses Buch zu lesen

Ereignisse selbst schreiben
Neues Code-Beispiel: Angenommen wir wollen ein UserControl, welches alle KnownColors in einer Listbox auflistet, sodass man auswählen kann, ohne den WinForms-ColorDialog jedesmal öffnen und schließen 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. Unlogischerweise geht das trotzdem (es geht nur mit Forms), und das ist ziemlich katastrophal, weil Microsoft damit die VB-Progger quasi verblödet, sodass diese alsbald nicht mehr klar 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)
   "Lege in uclColorSelector eine Public Property vom Typ Form1 an, initialisiere die, und dann kann der uclColorSelector 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, der leider noch gar nicht da ist.
   

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.

Der Design-Fehler "zu enge Kopplung" wird zu einem richtigen Hindernis, wenn man uclColorSelector mal in eine andere Solution einbauen möchte - das geht nämlich gar nicht: Weil es 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. Also ein Event muß her - diesmal von der Sender-Seite her implementiert:(Das <DefaultEvent()> - Attribut veranlasst übrigens den Form-Designer, beim Doppelklick auf meinen uclColorSelector gleich den korrekten EventHandler in den Code-Editor zu generieren - kenntmanja von Button.Click und Konsorten).
Is einfach - ne? Einfach Public Event SelectedColorChanged As EventHandler hinschreiben, und schon kann man sein eigenes Event raisen.

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 bisher nur bei Dilettanten erlebt (außer bei mir ;)), dass jmd. sich unterstanden hätten, von dieser Richtlinie abzuweichen (Ausnahme: EBC - event-driven Architecture - aber das ist 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, hat überhaupt keine Property! 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
Ein Event unterliegt strikten Einschränkungen: Es ist Readonly, man kann's nicht als Methoden-Argumente weiterreichen - ja man kann's 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-Klasse, ü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 aus der ersten Variante und dem hiesigen, generischen DelegatTypen EventHandler(Of ColorChangedEventArgs)

BenamungsRichtlinie
Obiges ist ein voll ausprogrammiertes Beispiel eines Events, und folgt den MS-Richtlinien, sowohl was die systematische Benamung aller beteiligten Elemente betrifft, als auch die Signaturen des Events und der OnEvent-Methode.

In der Praxis muß man entscheiden, wieviel Aufwand erforderlich ist. Tatsächlich ist erstere Variante - das SelectedColorChanged-Event ohne selbstdefiniertes EventArgs - etwas flexibler (die SelectedColor-Property braucht man ja eh) und es unterstützt so nebenbei Databinding (vorrausgesetzt man hat korrekt systematisch benamt).
Aber Databinding ist auch ein anderes Tutorial (naja - ich hab trotzdem eine Databinderei im Sample eingebaut)

Hier hänge ich mal ein Video an über die 4 Varianten, wie VisualStudio den Programmierer beim Abonnieren eines Events unterstützt:

1. Default-Event, generiert durch Doppelklick im Form-Designer
   
2. ausgewähltes Event aus der Event-Ansicht des Eigenschaften-Fensters
   
3. Auswahl von WithEvents-Variablen im Code-Editor
   
4. Abonnieren per AddHandler-Schlüsselwort
   

(Video: Events abonnieren)

anbei noch das (komische) Demo-Projekt. Naja - alles notwendige dazu ist ja im Video gesagt.

Jo, und EventArgs können sogar Methoden ausführen!

Etwa das DataGridViewCellPaintingEventArgs verfügt über Methoden wie .Paint(PaintParts), .PaintContent() und .PaintBackground().
Also die Tatsache, dass das EventArgs genau weiss, um welche Zelle es geht, wird hier genutzt, um die Zelle dann direkt zu bemalen.
Siehe zB coloriertes DatagridView