Hallo Marcus,
als Ingenieur hast Du wesentlich bessere Voraussetzungen,
denn Du weisst, was bei einer schlechten Konstruktion passieren kann -
Software-Entwickler (mit oder ohne Diplom) müssen sich das erst vorstellen ;-)
Zum Thema Casten steht das meiste unter
TryCast (jetzt deutscher Link).
TryCast verendet man dann, wenn die Konvertierung schief gehen könnte.
Denn sowohl DirectCast wie auch CType können zur Laufzeit fehlschlagen
und eine InvalidCastException auslösen (was das Programm zurückwirft).
Als Beispiel für oben konstruiert:
Wenn MdiParent nicht mehr frmMain sondern frmMainDasZweite ist,
z. B. weil das Formular auf anderem Wege eröffnet wurde, wird dort Nothing geliefert.
Und man kann entsprechend reagieren - wie mit dem Test gezeigt.
Denn alles andere (Toolstrip/Button) existieren ebenfalls nicht.
DirectCast verwendet man dann, wenn die Umwandlung (mit 99,999% Sicherheit)
nicht fehlschlagen kann und man keine Ausnahme erwarten muß.
Ein Beispiel wäre die Ereignisbehandlung.
Dort wird generell sender AS Object als erster Parameter verwendet.
Da man dort "weiss", dass ein Button.Click immer ein Button ist, kann man dort schreiben:
Private Sub OKCancelButton_Click(ByVal sender As Object, ByVal e As EventArgs) _
Handles OKButton.Click, CancelButton.Click
Dim button = DirectCast(sender, Button)
End Sub
(Das "Wissen" ist natürlich nur eine berechtigte Annahme und gilt nur, wenn man sich an die Regeln hält.)
Beide Operatoren funktonieren nur wenn die Typen direkt ableitbar sind,
und sind häufig die schnelleren.
CType wäre die allgemeinste Variante.
Eingesetzt wird sie bei Werttypen (Structure) - siehe
Strukturen und Klassen
Sie ist oft die langsamste - was auch daran liegt, dass Visual Basic u. U. einiges auf Vorrat dazustrickt,
weil man Strict Off und VB Classic Kompatibilität berücksichtigen muß (C# kennt das alles nicht).
Für die .NET Standardtypen kann man die eingebauten Operatoren wie CInt verwenden,
siehe Implizite und explizite Konvertierungen .
Zum Thema Delegaten:
Du hast sie oben (und anders wo) in Form von Ereignissen schon reichlich verwendet.
Ereignisse (Event ) basieren auf Delegaten, die per Konvention
Eventhandler am Ende heissen.
Der einfachste wäre
EventHandler , wenn keine Argumente übergeben werden müssen.
Benötigt man Argumente, so werden sie per Konvention von der Klasse
EventArgs abgeleitet.
Und weil das (fast) immer so ist, kann man Ereignisklassen (seit .NET 2.0) über den
EventHandler<
(Of < ( TEventArgs >
) > ) -Delegat erstellen.
Man kann Delegaten nicht nur für Ereignisse verwenden, sondern überall da,
wo man eine Methode übergeben will, die die Arbeit erledigt.
Da .NET nur typsichere Aufrufe zulässt, müssen Signaturen der Methoden (d. h. Parametertypen)
vorher festgelegt werden. Das geschieht mit der
Delegate-Anweisung . Womit im Hintergrund
eine Klasse erzeugt wird, die von
MulticastDelegate abgeleitet ist - EventHandler stammt auch davon ab.
Da man für jede Typ-Kombination einen braucht, hat man für die häufigsten Varianten in .NET 2.0
die generischen
Action-Delegaten , für Prozedur (Sub) Aufrufe und die
Func(TResult)-Delegaten
für Funktionen (Function) eingeführt. Dazu kommen noch einige weitere wie
Predicate(T) uam.
Ein Bereich, von man sie im Einsatz sieht, wären die Methoden von List(Of T) wie
ForEach oder
Find uam.
Und da es für eine oder wenige Zeilen etwas mühsam ist, jeweils eine Methode zu erstellen,
hat man anonyme Methoden eingeführt, allgemein als
Lambda-Ausdruck bezeichnet.
Die bilden wiederum die Grundlage für
LINQ (aber das in einem späteren Beitrag).
Für eine Standard-Anwendungsentwicklung muß man sie nicht zwangsläufig einsetzen,
auch wenn es den Code manchmal einfacher und flexibel machen kann.
Und wo man sie täglich verwendet (Ereignisse, LINQ) merkt man es meist gar nicht
(bis auf solchige wie das obige Problem ;-).
Gruß Elmar
