Wo ligt der unterschied

Bitte kannst du die Frage klarer stellen?
Ansonsten muss ich antworten, dass doch klar ins Auge fällt, dass das erste Snippet nur 1 Zeile hat, das andere dreizehnmal so viele - ein gewaltiger Unterschied!

nein, die snippets machen durchaus unterschiedliches - keine Ahnung was.
Es sieht einfach nur wirr aus, und wird nichtmal kompilieren.

Da das schlecht in meine Erklärung unten passt halte ich das direkt hier oben fest:
Das:

und das:

macht in Deinen beiden Beispielen keinen Unterschied. Es gibt Unterschiede zwischen Deinen beiden Beispielen, aber die haben nichts damit zu tun, ob man was erst einer lokalen Variable zuweist. Deshalb vereinfache ich diesen Teil in allen Codeschnipseln.
Also:


Hier vermischen sich mehrere Konzepte ein bisschen. Lass mich also genauer erklären:

1.
Einen Delegattyp deklarieren funktioniert so: Delegate Sub T(...) bzw. Delegate Function T(...) As ....
Das deklariert den nicht-abstrakten Delegattyp T. Jeder nicht-abstrakte Delegattyp spezifiziert eine Signatur. Das heißt, eine Instanz eines solchen Delegattypen zeigt auf eine Methode, die eben jene Signatur hat oder damit kompatibel ist. (Kompatibel bedeutet, dass Vererbung beachtet wird, also z.B. eine Instanz eines Delegattypen, der eine Katze als Parameter entgegennehmen muss, auch auf eine Methode zeigen darf, die alle Arten von Tieren entgegennimmt.)

2.
Delegaten instanziieren funktioniert so: New T(M).
T ist ein Delegattyp. Wichtig ist hier, dass es sich um einen nicht-abstrakten Delegattyp handelt. Ist wie bei ganz normalen Klassen: Katze ist ein ("erbt von") Tier. Du kannst eine Katze erstellen, aber kein Tier, weil Tier was abstraktes ist.
M ist ein Methodenausdruck. Hier gibt es diese zwei Möglichkeiten:

1. AddressOf N, wobei N der Name einer anderswo deklarierten Methode ist, welche eine mit dem Delegaten kompatible Signatur haben muss.
   
2. Ein Lambdaausdruck, wobei der Lambdaausdruck eine mit dem Delegaten kompatible Signatur haben muss oder VB etwas "nachhelfen" können muss. Also z.B. wenn der Delegattyp Parameter spezifiziert, der Lambdaausdruck aber keine Parameter entgegennimmt, dann bekommt der Lambdaausdruck im Hintergrund trotzdem Parameter, die einfach "unsichtbar" sind.

Beachte: In vielen Fällen ist es erlaubt, nur M als Ausdruck hinzuschreiben und der Compiler baut im Hintergrund die Instanziierung drumherum selbst zusammen. Wenn das Ziel für den Ausdruck ein nicht-abstrakter Delegattyp ist, dann wird als T eben jener Typ verwendet. Wenn der Typ ein abstrakter Delegattyp (z.B. beim Aufruf von Me.Invoke) oder nicht bekannt ist (z.B. bei Dim x = D mit Option Infer On), dann wird im Hintergrund ein anonymer Delegattyp deklariert und verwendet.

3.
Die Methode aufrufen, auf die eine Instanz eines Delegattyps zeigt, funktioniert so: D.Invoke(..), oder abgekürzt D(...), was aber auch nur zu vorherigem kompiliert.
D ist irgend ein Ausdruck, der eine Instanz eines Delegattyps ergibt. Also zum Beispiel eine lokale Variable (wie in deinem zweiten Codeschnipsel) (aber jetzt nicht mit Me.Invoke verwechseln, welches damit nichts zu tun hat!), ein Parameter, ein Feld oder - wenn auch etwas unsinnig - eine direkte Instanziierung wie in Schritt 2.

4.
Oben erwähne ich immer wieder "nicht-abstrakte Delegattypen".
Es gibt genau zwei abstrakte Delegattypen: System.Delegate und System.MulticastDelegate (erbt von System.Delegate). Diese beiden Delegattypen sind vom .NET-Framework vorgegeben. Sie besitzen keine eigene Signatur und deshalb auch keine Invoke-Methode, wie in Schritt 3 gezeigt und man kann deshalb auch keine Instanz davon erstellen. Ist wie gesagt genau wie mit Katzen und Tieren.
Wie ruft Me.Invoke, welches ja einen System.Delegate entgegennimmt, dann die Methode auf, wenn es keine Invoke-Methode gibt? Nun, es gibt da noch die DynamicInvoke-Methode. Die nimmt ein Object-Array entgegen und macht im Grunde genommen das: D.Invoke(Args(0), Args(1), Args(2), ...). Also das erste Objekt im Array wird als erster Parameter verwendet, das zweite Element als zweiter Parameter, und so weiter. Das ist natürlich Fehleranfällig, weil der Compiler nicht wissen kann, ob die Anzahl an Parametern und deren Typen stimmen. Das wird erst zur Laufzeit geprüft und löst im Fehlerfall eine ArgumentException aus.
Also das sind die abstrakten Delegattypen.
Alle nicht-abstrakten Delegattypen erben von einem dieser beiden abstrakten Delegattypen. Genau genommen ist die Unterscheidung zwischen Delegate und MulticastDelegate unnütz und wurde nur behalten, weil es vor Release von .NET Framework 1.0 zu aufwändig gewesen wäre, die beiden Typen zusammenzufassen: blogs.msdn.microsoft.com/brada…te-and-multicastdelegate/ und genau genommen erben alle nicht-abstrakten Delegattypen einfach von System.MulticastDelegate.
Jeder Delegattyp, den Du wie in Schritt 1 deklarierst, ist ein nicht-abstrakter Delegattyp, also mit Signatur, Invoke-Methode, und so weiter.
Sinn der abstrakten Delegattypen ist einfach, dass man einen gemeinsamen Typ hat, mit dem man arbeiten kann. Wie eben die Me.Invoke-Methode.


Mit diesem Wissen ausgestattet kann man jetzt Deine Codeschnipsel zerpflücken. Ich habe sie allerdings der Verständlichkeit wegen etwas aufgeräumt.
Der einfachste Weg, herauszufinden, was im Hintergrund passiert, ist, den Code in einem Testprojekt zu kompilieren und anschließend mit z.B. ILSpy zu dekompilieren. Da kommt dann das heraus:




Also Schnipsel 2 ist die elementarste Form, die man haben kann. Du deklarierst einen Delegattyp, erstellst davon eine Instanz die auf die ClearButtons-Methode zeigt und schmeißt die Instanz in die Me.Invoke-Methode. Keine Magie, alles ganz einfach.

Bei Schnipsel 1 hast Du einen Lambdaausdruck. Der wird zu einer anonymen Methode kompiliert. Der Inhalt dieser anonymen Methode ist einfach ein Aufruf an die ClearButtons-Methode. Da Du die Instanziierung nicht explizit hingeschrieben hast und die Me.Invoke-Methode einen abstrakten Delegattyp entgegennimmt, es also keinen nicht-abstrakten Delegattyp gibt, der verwendet werden könnte, wird ein anonymer Delegattyp deklariert und an der Stelle instanziiert. Ab jetzt gibt es nur noch ein paar kleine Details, in denen sich der Code von Schnipsel 2 unterscheidet. Also z.B. dass der anonyme Delegattyp in Schnipsel 1 ohne Namespace in der Assembly deklariert wird, aber so genau muss man es dann auch nicht wissen.



Ein kleiner Nachtrag zu Schritt 2: Wenn M eine Instanzmethode ist, dann "merkt" sich die Instanz des Delegattyp an welcher Instanz die Methode, auf die gezeigt wird, aufgerufen werden muss.

In diesem Beispiel zeigen DA und DB zwar auf die gleiche Methode aber "merken" sich unterschiedliche Instanzen.
Wenn Du also Me.Invoke(New TestDelegate(AddressOf ClearButtons)) hinschreibst, dann steht da implizit eigentlich Me.Invoke(New TestDelegate(AddressOf Me.ClearButtons)). Da es sich also um eine Instanzmethode handelt, merkt sich die Instanz des Delegattyps hier ebenfalls, was Me ist.


Und noch ein Nachtrag zur Nomenklatur:
Ich habe mich bemüht, um Missverständnisse zu vermeiden, hier immer schön säuberlich "Instanz eines Delegattyps" hinzuschreiben. Gebräuchlich ist es aber, Instanzen von Delegattypen einfach nur "Delegaten" zu nennen. Also z.B. "Du erstellst einen Delegat, der auf die ClearButtons-Methode zeigt.

Niko Ortner schrieb:

(Kompatibel bedeutet, dass Vererbung beachtet wird, also z.B. eine Instanz eines Delegattypen, der eine Katze als Parameter entgegennehmen muss, auch auf eine Methode zeigen darf, die alle Arten von Tieren entgegennimmt.)

Umgekehrt, oder nicht? Der Delegattyp erwartet einen String, dann kann die Instanz des Delegattypen nicht auf eine Methode zeigen, die nur Objects akzeptiert. In deinem Beispiel: Der Delegattyp erwartet "Tier", dann darf ich natürlich auf eine Methode verweisen, die nur Katzen akzeptiert.

Niko Ortner schrieb:

Es gibt genau zwei abstrakte Delegattypen: System.Delegate und System.MulticastDelegate (erbt von System.Delegate).

Inne Praxis gibts glaub nur einen, den MultiCast.
Ich hab jdfs. noch nie einen Delegaten am Wickel gehabt, der nicht Multicast gewesen wäre, und ich hab auch kein Plan, wie ich einen Delegaten erstellen sollte, der nicht Multicast ist.
Aber vlt. wisst ihr da ja was...

@ErfinderDesRades Er schrieb ja ein paar Absätze weiter auch:

Niko Ortner schrieb:

Genau genommen ist die Unterscheidung zwischen Delegate und MulticastDelegate unnütz und wurde nur behalten, weil es vor Release von .NET Framework 1.0 zu aufwändig gewesen wäre, die beiden Typen zusammenzufassen: blogs.msdn.microsoft.com/brada…te-and-multicastdelegate/ und genau genommen erben alle nicht-abstrakten Delegattypen einfach von System.MulticastDelegate.

Arby schrieb:

Umgekehrt, oder nicht?

Nein, schon so rum.
Stell es Dir so vor:

Die FeedAnimal-Methode darf Katzen und andere Tiere entgegennehmen. In die Invoke-Methode wird eine Katze reingeschmissen, der Delegattyp spezifiziert ja schließlich, dass eine Katze entgegengenommen wird. Klappt also.


Aber anders rum wäre es falsch:

Die FeedCat-Methode darf nur Katzen entgegennehmen. In die Invoke-Methode wird ein Hund reingeschmissen, der Delegattyp spezifiziert ja schließlich, dass alle Arten von Tieren entgegengenommen werden. Die FeedCat-Methode bekommt jetzt einen Hund, obwohl sie nur Katzen entgegennehmen kann. Das ist also falsch.

Nach dem gleichen Prinzip (hier aber optisch andersrum) werden Rückgabetypen behandelt. Also eine Instanz eines Delegattyps, dessen Signatur ein Tier zurückgibt, darf auf eine Methode zeigen, die eine Katze zurückgibt.

Eine nette Sache auch: Wenn die Signatur eines Delegattyps keinen Wert zurückgibt, darf man bei der Instanziierung auch einen Methodenausdruck verwenden, dessen Signatur einen Wert zurückgibt:

Das wird von .NET nicht unterstützt. Hier baut der VB-Compiler eine anonyme Lambdamethode ein, die GetThing aufruft und den zurückgegebenen Wert verwirft (und selbst nichts zurückgibt), und lässt den Delegat darauf zeigen (statt direkt auf die GetThing-Methode).

In C# ist das nicht erlaubt.