|
Sicher sind Ihnen, vor allem beim Einsatz von API-Funktionen, in den Original-Deklarationen Datentypen wie hWnd, hDC, hIcon und dergleichen mehr begegnet. In C und in anderen Programmiersprachen sind solche Datentyp-Deklarationen durchaus üblich, auch wenn sie letztlich nicht wirklich einen neuen Datentyp repräsentieren. Aus der Sicht von VB werden die meisten dieser Datentypen als Datentyp Long interpretiert - so auch die oben genannten. Insofern haben solche Datentypen keine sich zur Laufzeit auswirkende funktionale Relevanz. Hingegen diesen sie in erster Linie der Sicherheit - falsch deklarierte Datentypen, etwa bei Funktions-Parametern, werden vom Kompiler abgewiesen. So wird ein C(++)-Programmierer zum Beispiel einer API-Funktion, die in einem Parameter ein Fenster-Handle (hWnd) erwartet, keinen Gerätekontext (hDC) in eben diesem Parameter übergeben können.
In Visual Basic können Sie leider nicht so einfach solche eigenen Datentypen ins Rennen schicken - aber es geht dennoch. Schauen wir uns einmal an, welche Möglichkeiten vielleicht in Betracht kommen könnten, um etwa den Datentyp hWnd zu kreieren.
Die einzigen Möglichkeiten in Visual Basic, eigene Datentypen zu deklarieren, sind das Anlegen eines so genannten "Benutzerdefinierten Datentyps" oder das Anlegen einer Enumeration. Ein "Benutzerdefinierter Datentyp" scheidet aus praktischen Gründen aus:
Public Type hWnd
.Irgendwas As Long
End Type
Abgesehen davon dass die Syntax ziemlich umständlich wäre, würde eine Deklaration wie
Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(hWnd As hWnd, ...
den gewünschten Effekt verfehlen - der Aufruf
Dim nWnd As hWnd
nWnd.Irgendwas = Me.hWnd
SendMessage nWnd, ...
würde wirkungslos ausgeführt.
Eine Enumeration sieht dagegen schon vielversprechender aus:
Public Enum hWnd
Irgendwas
End Enum
Die Deklaration würde nun so lauten:
Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(ByVal hWnd As hWnd, ...
Und der Aufruf würde keine syntaktischen Verrenkungen erfordern oder Probleme aufwerfen:
SendMessage Me.hWnd, ...
Etwas irritierend ist allerdings, dass der IntelliSense-Mechanismus der Entwicklungsumgebung jedes Mal diesen ominösen "Irgendwas"-Wert anzubieten versucht.
Einfach weglassen geht jedoch nicht:
Public Enum hWnd
End Enum
Dies würde beim Kompilieren mit einer Fehlermeldung quittiert werden:
"Fehler beim Kompilieren: Enum ohne Elemente nicht möglich"
Da Enumerationen zur COM-Welt gehören, und da die COM-Welt den führenden Unterstrich als Kennzeichen für Unsichtbarkeit kennt, könnte man doch...?
Public Enum hWnd
_Irgendwas
End Enum
...oder doch nicht? Der Syntaxchecker der IDE moniert diese Schreibweise auf der Stelle. Letzter Versuch, die VB-IDE mit ihren eigenen Mitteln zu schlagen. Sie erlaubt nämlich in Grenzen die Verwendung von Begriffen, die den Syntaxregeln widersprechen, wenn solch ein Begriff in eckige Klammern eingeschlossen wird:
Public Enum hWnd
[_Irgendwas]
End Enum
oder - wenn schon, denn schon - ganz konsequent:
Public Enum hWnd
[_]
End Enum
Damit hätten wir fast unser Eingangs gestecktes Ziel erricht. Sie können nun einen Parameter oder eine Variable problemlos als Ihren neuen Datentyp deklarieren und verwenden:
Public Enum MeinDatenTyp
[_]
End Enum
Sub MeineSub(MeinParameter As MeinDatenTyp)
'...
End Sub
' ...
Dim nVar As MeinDatenTyp
MeineSub nVar
Eines können wir so jedoch nach wie vor nicht erreichen: Die Ablehnung durch den Kompiler, wenn eine Variable eines falschen Datentyps übergeben wurde. Aus VB-Sicht handelt es sich nämlich nach wie vor um Long-Werte, die der Kompiler natürlich anstandslos und untereinander austauschbar akzeptiert. Aber vielleicht hilft Ihnen dieser kleine Trick zumindest, Ihren Über- und Durchblick über und durch Ihren eigenen Code (oder den Ihrer Kollegen) zu wahren.
|