) lesbar bzw. zu anderen Programmteilen nicht mehr kompatibel werden. Also besser bei der Vorgabe bleiben.
Wir haben in den bisherigen Lektionen schon einige API-Aufrufe (Application Programming Interface) kennengelernt, da wird es allmählich Zeit, daß wir uns mal grundsätzlich damit befassen.
VB bietet zwar inzwischen einen recht umfangreichen Befehlsvorrat, dennoch kommt es nicht selten vor, daß man damit auf Grenzen stößt. Das ist jedoch kein allzugroßes Problem, kann man doch jederzeit auf zahlreiche Funktionen zurückgreifen, die das Betriebssystem standardmäßig mitliefert. Man muß "nur" wissen, wo diese stecken und wie man sie aufruft.
Zur Frage nach dem "Wo": Es gibt wohl einige tausend Funktionen und es ist schwer, einen Überblick zu bekommen. Viele davon sind jedoch nicht relevant, weil sie entweder unter VB schon mit einfacheren Mitteln zu erhalten sind, oder weil sie von VB aus nicht nutzbar sind.
Leider gibt die VB-Dokumentation noch immer nur sehr mageren Aufschluß über APIs und viele Beschreibungen sind nur in der für VB-Programmierer sehr gewöhnungsbedürftigen C-Syntax zu erhalten. Hier kann ich nur auf *das* Standardwerk zu dem Thema verweisen: Dan Appleman, Visual Basic Programmer's Guide to the Win32 API, leider nur in Englisch, aber dafür mit zahlreichen guten Beispielen.
Das "Wie" läßt sich hier nur grundsätzlich beantworten: Um eine API-Funktion zu nutzen, muß man diese erstmal deklarieren, d.h. man muß dem Programm sagen, welche Funktion man nutzen will, in welcher Bibliothek (DLL) sie sich befindet und welche Parameter übergeben werden sollen. Wir haben das schon kennengelernt:
Declare Function WritePrivateProfileString Lib "kernel32" Alias _
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, _
ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName _
As String) As Long
Wir brauchen uns diesen Bandwurm nicht zu merken, wenigstens hier bietet uns VB eine Erleichterung: die gebräuchlichsten API-Aufrufe und Konstanten sind in der Datei WINAPI.TXT gelistet. Man kann auf diese direkt aus VB mit Hilfe des API-Viewer-AddIns zugreifen (falls nicht bereits installiert, muß dies über den AddIn-Manager nachgeholt werden).
Eine gute Alternative dazu bietet das Freeware-AddIn Win32API Viewer (WIN32API.ZIP, Bib.21), das auch noch eine praktische Suchfunktion beinhaltet, ansonsten aber mit dem VB-AddIn kompatibel ist.
Die Deklaration gehört grundsätzlich in ein .bas-Modul, damit man von überall darauf zugreifen kann. Nachdem der Aufruf deklariert ist, kann er wie ein eigenes Unterprogramm aufgerufen werden.
Schauen wir uns die Teile der Deklaration nochmal genauer an:
Declare Function Einleitung der Deklaration für eine Funktion
Declare Sub oder ein Unterprogramm (abhängig von der verwendeten Funktion)
WritePrivateProfileString der im Aufruf verwendete Name der Funktion
Man könnte hier auch einen eigenen Namen angeben, wenn einem die Vorgabe nicht gefällt, dies birgt jedoch die Gefahr, daß Programme sehr schnell nicht mehr für andere (oder auch einen selbst ) lesbar bzw. zu anderen Programmteilen nicht mehr kompatibel werden. Also besser bei der Vorgabe bleiben.
Dei Endung wird hier üblicherweise weggelassen. Wir finden die Bibliothek im System-Verzeichnis als "kernel32.dll". Wer mag, kann sich diese DLL einmal mit QuickView oder ShowDep angucken und findet dann alle Funktionen unter "Exports" gelistet. Schaut man jedoch nach "WritePrivateProfileString", findet man nur zwei ähnliche klingende Funktionen, nämlich
Was hat es damit auf sich? Werden einer DLL Zeichenketten übergeben, so könnte diese Zeichenkette in Unicode- oder ANSI-Format kodiert sein. Das "A" am Ende steht bei einer Funktion für Ansi, das "W" für Unicode. In VB arbeiten wir üblicherweise mit ANSI-Zeichenketten (die Unicode-Funktionen sind nur unter NT verfügbar) und benutzen daher stets die Funktionen mit dem "A" am Ende. Bei Aufrufen, die Zeichenketten übergeben, kommt daher grundsätzlich noch ein "Alias"-Teil hinzu:
Jetzt wird tatsächlich die Funktion WritePrivateProfileStringA aufgerufen, obwohl wir im Programm selber nur noch WritePrivateProfileString angeben.
Wichtig: 32-Bit-API-Funktionen sind case-sensitiv, wir müssen also streng auf korrekte Schreibweise achten!
Und noch ein Hinweis: Auch bei Funktionen, die keine Strings übergeben, kann das Alias notwendig werden, nämlich dann, wenn in der Funktion Namen benutzt werden, die in VB nicht als Funktionsnamen erlaubt sind (es gibt z.B. sehr häufig Funktionen, die mit einem Unterstriche beginnen, z.B. "_lopen").
Jetzt kommt noch die Deklaration der übergebenen Parameter:
Bei den Variablennamen könnten wir zwar grundsätzlich auch eigene Bezeichnungen wählen, es ist jedoch kaum der Mühe wert, da sich dies nur auf die Deklaration bezieht, schließlich geht es hier nur um Platzhalter, die später beim Aufruf im Programm durch einen chten Wert oder eine Variable ersetzt werden.
Bei den meisten Variablen erwartet die API-Funktion einen Wert, keine Variable (Zeiger auf eine Stelle im Speicher), deshalb finden wir hier in der Regel den Präfix "ByVal". Und auch die Typdeklaration ist wichtig und darf üblicherweise nicht verändert werden.
Gelegentlich sind Parameter optional, das muß man jeweils der Dokumentation zu den Aufrufen entnehmen.
Das Anhängsel
gibt schließlich den Typ des Rückgabewertes an, sofern es sich um eine Funktion handelt.
Mit diesem Grundwissen können wir uns an so ziemlich jeden API-Aufruf wagen, der in der Liste verzeichnet ist. Ein paar Regeln sollten wir jedoch beachten, um nicht Schiffbruch zu erleiden:
Mit einem API-Aufruf verlassen wir die VB-"Schutzhülle", d.h. machen wir hier etwas falsch, dann bekommen wir von VB keine "vernünftige" Fehlermeldung zurück, da wir uns hier auf einer anderen Ebene befinden. "Allgemeine Schutzverletzungen" mit kryptischen Fehlermeldungen oder einfach kommentarlose Abstürze des Programms sind hier nicht ganz selten. Unter VB3 bedeutete das in der Regel einen Systemabsturz, unter VB5/6 müssen wir damit rechnen, daß VB abstürzt, wenn wir hier fahrlässig vorgehen. Vor allem wenn man wenig Erfahrung damit hat, empfiehlt es sich also, vor einem Testlauf den aktuellen Stand zu sichern, um sich unnötige Mehrarbeit zu ersparen.
Die häufigsten Fehlerquellen sind dabei: nicht oder falsch deklarierte Variablen, auch enpfiehlt es sich, eine Variable vor der ersten Benutzung zu initialisiern (z.B. mit Leerzeichen).
Wenn man dies beachtet, hat man aber mit API-Aufrufen ein reiches Arsenal an Zusatzfunktionen zur Verfügung. Die am häufigsten benutzten DLLs sind:
Diese Funktionen sind alle schon im Betriebssystem enthalten und wir brauchen sie mit unseren Programmen nicht mitzuliefern und zu installieren.
So, jetzt sind Eurem Forscherdrang keine Grenzen mehr gesetzt!
© Copyright 1998-2000 J.Behling 
Weitergabe und Druck (auch in Teilen, mit Ausnahme von Privatgebrauch) ohne ausdrückliche Genehmigung der Autorin untersagt.