<\/p>\n
Access stellt ausreichend Bordmittel zur Programmierung von Datenbankanwendungen zur Verfügung. Dazu gehören die Benutzerschnittstellen zur Gestaltung der Datenbankobjekte wie Tabellen, Abfragen, Formulare und Berichte sowie die Möglichkeit, Abläufe ereignisgesteuert per Makro oder VBA zu automatisieren. Manchmal reichen die vorhandenen Befehle aber nicht aus. In dem Fall greifen Sie auf die Prozeduren der Windows-API (Application Programming Interface) zu. Mit API-Prozeduren können Sie Ihre Anwendungen alles machen lassen, was Windows auch kann.<\/b><\/p>\n
Die Windows-API verfügt über eine sehr große Anzahl von Befehlen. Der vorliegende Beitrag kann Ihnen aber aus Platzgründen nur einen kleinen Einblick in die Möglichkeiten der API-Programmierung geben. Nach einer kurzen Einführung, in der die wichtigsten Begriffe und die technischen Grundlagen erklärt werden, folgt der Praxisteil mit einigen Beispielen. Die Beispiele sind so ausgewählt, dass Sie sie gut in Ihre eigenen Anwendungen übernehmen können.<\/p>\n
Das Datenbanksystem Microsoft Access <\/b>ist Windows-kompatibel. Daraus ergeben sich für den Entwickler große Vorteile. Er kann mit Access Datenbanken erstellen, welche die Eigenschaften von Windows wie selbstverständlich ausnutzen. Dabei muss der Entwickler sich nicht damit abmühen, das Aussehen von Formularen, Berichten und den darin enthaltenen Steuerelementen zu programmieren. Access stellt Werkzeuge zur Verfügung, mit denen die Erstellung solcher Objekte zum Kinderspiel wird. Der Entwickler muss lediglich die verschiedenen Ereignisse per VBA programmieren, mit denen die Anwendung auf die unterschiedlichen Benutzereingaben reagiert.<\/p>\n
Streng genommen handelt es sich bei den Befehlen nicht nur um VBA-Befehle. VBA selbst enthält nur die Befehle, die von den Microsoft-Anwendungen wie zum Beispiel Word, Excel und eben Access genutzt werden können. Um eine Datenbank zu programmieren, benötigen Sie darüber hinaus mindestens noch die Bibliotheken Microsoft Access x.0 Object Library <\/b>und eine Datenzugriffsbibliothek wie in den neueren Versionen von Access die Bibliothek Microsoft Office x.0 Access Database Engine Object Library<\/b>. Die beiden Bibliotheken enthalten die Befehle zur Steuerung der Datenbankobjekte von Access und zum Zugriff auf die in der Datenbank gespeicherten Daten.<\/p>\n
Windows selbst kennt über die Befehle der drei genannten Bibliotheken hinaus noch viel mehr Befehle. Diese sogenannten API-Befehle können Sie auch von Access aus aufrufen. In den folgenden Abschnitten erfahren Sie, wie Sie unterschiedliche Befehle der Windows-API aufrufen können und welche Vorraussetzungen dazu erfüllt sein müssen.<\/p>\n
Die wesentlichen zum Betrieb von Windows notwendigen Prozeduren sind auf einige wenige Bibliotheken verteilt. Die folgenden drei sind die wichtigsten: Kernel32.dll<\/b>, User32.dll <\/b>und GDI32.dll<\/b>.<\/p>\n
Die Bibliothek Kernel32.dll <\/b>macht den eigentlichen Kern von Windows aus. Zu den Aufgaben der Prozeduren dieser Bibliothek gehören die Auswertung von Tastatureingaben, die Ausgabe auf dem Bildschirm, die Verwaltung der laufenden Anwendungen, die Verwaltung des Dateisystems und andere, die aber für den Einsatz im Zusammenhang mit Access eine untergeordnete Bedeutung haben.<\/p>\n
Die Prozeduren der Dynamic Link Library User32 <\/b>dienen hauptsächlich der Bereitstellung der Benutzerschnittstelle, das heißt der Fenster, des Mauszeigers, des Ribbons und der Menüs und so weiter. Das öffnen, Schließen und Verschieben der Fenster gehört zu den Aufgaben der User32.dll<\/b>.<\/p>\n
Das Graphics Device Interface (GDI32.dll<\/b>) dient der Ausgabe von grafischen Elementen wie Grafiken, Text, Farben et cetera. Es dient praktisch als Schnittstelle zwischen dem Benutzer und dem Ausgabegerät. Als Ausgabegeräte kommen dabei alle möglichen Geräte infrage – sowohl unterschiedliche Monitore als auch Drucker und andere Ausgabegeräte. Windows stellt für alle möglichen Formate einen Treiber zur Verfügung. <\/p>\n
Neben den genannten Bibliotheken gibt es noch einige weitere, wie etwa die COMDLG32.dll<\/b>, die unter anderem die Dialoge zum öffnen und Speichern von Dateien und zur Auswahl von Farben und von Zeichensätzen zur Verfügung stellt.<\/p>\n
Wie hier zu erkennen ist, sind die zum Betrieb von Windows notwendigen Prozeduren nach Aufgaben geordnet auf unterschiedliche Bibliotheken aufgeteilt. Durch diese modulare Bauweise ist Windows leicht erweiterbar. Dementsprechend sind im Laufe der Zeit noch einige weitere Bibliotheken hinzugekommen. Sie stellen zum Beispiel neue Steuerelemente zur Verfügung (COMCTL32.dll<\/b>), ermöglichen den Austausch von E-Mail (MAPI32.dll<\/b>) oder dienen zur Verwaltung von Netzwerken (NETAPI32.dll<\/b>).<\/p>\nWo finde ich die API-Prozedur für meine Zwecke<\/h2>\n
Ohne entsprechende Dokumentation der Prozeduren der Windows-API ist es sehr schwer, bestimmte Aufgaben mit Hilfe der API zu lösen. Sie müssen also zunächst eine geeignete API-Prozedur für Ihre Aufgabe finden. Das zweite Problem ist, dass die meisten Prozeduren der API-Bibliotheken in C programmiert sind. Dementsprechend sind sie auch für den Aufruf von C-Programmen ausgelegt. Vor allem wegen der unterschiedlichen Variablentypen in Visual Basic und in C kann der Aufruf einer solchen Funktion manchmal Probleme bereiten. Es gibt aber genügend Quellen, die den Aufruf von API-Funktionen aus Visual Basic heraus beschreiben. Neben diversen Fachzeitschriften, in denen immer wieder Beiträge zum Thema API auftauchen, soll an dieser Stelle auf ein Buch hingewiesen werden, das zwar leider englischsprachig ist, aber von vielen als API-Bibel bezeichnet wird: Dan Appleman“s „Visual Basic Programmer“s Guide to the Win32 API“. Wenn Sie also Gefallen an der Integration von API-Funktionen in Ihre Anwendungen finden, erfahren Sie dort mehr.<\/p>\n
Sie können API-Funktionen nicht wie gewöhnliche VBA-Prozeduren aufrufen. Sie müssen die gewünschte Prozedur zunächst deklarieren. Strenggenommen werden die VBA-Befehle und die Befehle zur Verwaltung der Datenbankobjekte auch deklariert – allerdings funktioniert das auf eine andere Weise und wird normalerweise direkt beim öffnen von Access erledigt. Die Deklaration dieser und anderer Bibliotheken nehmen Sie vor, indem Sie mit einem Verweis direkt die ganze Bibliothek verfügbar machen. Um einen solchen Verweis zu setzen, öffnen Sie ein beliebiges Modul in der Entwurfsansicht und wählen den Menübefehl Extras|Verweise<\/b>. Im Dialog Verweise<\/b> (s. Bild 1) können Sie durch Markieren der Kontrollkästchen Verweise auf die einzelnen Bibliotheken setzen.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2016_02\/pic_1032_004.png\")
<\/p>\n
Bild 1: Die Funktionen einiger Bibliotheken können per Verweis referenziert werden.<\/span><\/b><\/p>\n Die Deklaration von API-Prozeduren ist nicht ganz so einfach. Sie müssen jede API-Prozedur separat deklarieren. Bevor Sie mit dem ersten Beispiel beginnen, soll hier kurz die Syntax der Deklaration einer API-Prozedur erläutert werden.<\/p>\n Allgemein sieht die Syntax folgendermaßen aus:<\/p>\n Mit dem ersten Parameter, Public <\/b>oder Private<\/b>, geben Sie an, ob die Funktion nur innerhalb des Moduls Gültigkeit hat, oder ob sie anwendungsweit aufgerufen werden kann. Lassen Sie den ersten Parameter weg, hat die Funktion anwendungsweite Gültigkeit.<\/p>\n Die Declare<\/b>-Anweisung weist darauf hin, dass eine externe Funktion deklariert wird.<\/p>\n Als nächstes Schlüsselwort geben Sie wie bei der Programmierung einer VBA-Prozedur entweder das Schlüsselwort Function <\/b>oder Sub <\/b>an – je nachdem, ob die Prozedur einen oder mehrere Werte zurückgibt oder nicht. In der Regel bekommen Sie es aber mit Funktionen zu tun.<\/p>\n Unter Name <\/b>geben Sie den Namen der API-Prozedur an. Unter dem hier angegebenen Namen rufen Sie die Prozedur von Ihren eigenen Prozeduren aus auf. In der Regel ist das auch der Name, unter dem die Prozedur in der jeweiligen DLL abgelegt ist. Es gibt aber manche API-Prozeduren, deren Name nicht den VBA-Konventionen für Prozedurnamen entspricht. In dem Fall wird der eigentliche Name der API-Prozedur hinter dem Schlüsselwort Alias als aliasname<\/b> angegeben. Zum Aufruf der API-Prozedur benutzen Sie aber die unter Name <\/b>angegebene Bezeichnung.<\/p>\n Nach dem Schlüsselwort Lib <\/b>folgt der Name der Bibliothek, in der die Prozedur abgelegt ist. Es gibt drei unterschiedliche Arten, die Bibliothek anzugeben. Bei den drei Bibliotheken Kernel32<\/b>, User32 <\/b>und GDI32 <\/b>reicht die Angabe des Namens ohne Dateinamenendung. Bei allen anderen Bibliotheken geben Sie die Dateinamenendung an. Manchmal müssen Sie zusätzlich den Pfad der Bibliothek angeben. Das ist der Fall, wenn sich die Bibliothek nicht in den folgenden Verzeichnissen befindet:<\/p>\n Für den Parameter ArgumentList <\/b>geben Sie die Argumente an, die beim Aufruf der Prozedur übergeben werden. Die übergabe von Argumenten kann auf zwei Arten erfolgen. Welche der beiden Arten zu wählen ist, gibt die jeweilige Prozedur vor. Entweder Sie übergeben den Parameter als Wert und setzen dem Parameter das Schlüsselwort ByVal <\/b>voran, oder Sie übergeben die Speicheradresse des Parameters. Geben Sie dann entweder das Schlüsselwort ByRef <\/b>oder gar kein Schlüsselwort an.<\/p>\n übergeben Sie den Parameter als Wert, erhält die DLL nur eine Kopie des Parameters. Nachdem der Parameter bearbeitet wurde, wird die Kopie über das Original geschrieben. Wenn Sie hingegen eine Referenz übergeben, also einen Verweis auf die Adresse des Parameters, kann die DLL direkt auf den Parameter zugreifen.<\/p>\n Wann man welche Art der Parameterübergabe wählt und warum, wird erst deutlich, wenn man sich eingehender mit den unterschiedlichen Variablenarten in Visual Basic und C beschäftigt. In den später vorgestellten Beispielen wird die Art der Parameterübergabe jeweils angegeben. Zu der Parameterübergabe in weiteren API-Prozeduren erfahren Sie mehr in der einschlägigen Fachliteratur.<\/p>\n Hinter dem Schlüsselwort As <\/b>geben Sie schließlich den Datentyp an. Mehr über die in API-Aufrufen verwendeten Datentypen erfahren Sie im nächsten Abschnitt.<\/p>\n Die zu verwendenden Datentypen werden ähnlich wie die Art der Parameterübergabe durch die aufzurufende Prozedur festgelegt. üblicherweise finden hier die in VB üblichen Datentypen Verwendung.<\/p>\n Eine Ausnahme ist der Datentyp Any<\/b>. Er wird nur in Zusammenhang mit dem Aufruf von API-Prozeduren eingesetzt. Ein Parameter des Datentyps Any <\/b>kann unterschiedliche Datentypen annehmen, zum Beispiel String <\/b>und Long<\/b>. Wenn Ihnen ein solcher Datentyp begegnet, ist meist ein weiterer Parameter nicht weit, in dem der für den Parameter gültige Datentyp übergeben wird.<\/p>\n Eine weitere Ausnahme sind benutzerdefinierte Datentypen. Parameter eines benutzerdefinierten Datentyps bestehen meist aus mehreren Parametern, die sich auf ein einziges Objekt beziehen. Solche Datentypen müssen im Deklarationsteil eines Moduls deklariert werden. Anschließend müssen Sie den Namen des benutzerdefinierten Datentyps der gewünschten Variablen zuweisen.<\/p>\n Es gibt zwei sinnvolle Möglichkeiten, API-Prozeduren zu deklarieren. Entweder Sie nehmen die Deklaration aller API-Funktionen und benutzerdefinierten Datentypen in einem eigens dafür angelegten Modul vor. Auf diese Weise ist es ab einer gewissen Menge Deklarationen leichter, die übersicht zu behalten. Wenn Sie hingegen wissen, dass Sie eine bestimmte API-Funktion nur in einer Prozedur aufrufen, sollten Sie die Deklaration und die aufrufende Prozedur in einem Modul unterbringen. So können Sie die Komponenten im Paket kopieren und in anderen Anwendungen verwenden.<\/p>\n Leider sind die Kenntnisse einiger theoretischer Grundlagen bei der Benutzung der Windows-API unumgänglich. Da die API weit über 1.000 Prozeduren kennt, können Sie sich vorstellen, dass nicht alles Wichtige in den vorangegangenen Abschnitten untergebracht werden konnte. In den folgenden Beispielen zum praktischen Umgang mit den Prozeduren der Windows-API werden sich deshalb immer wieder kleine Abschnitte mit den theoretischen Hintergründen beschäftigen.<\/p>\n Da der vorliegende Beitrag nicht alle API-Prozeduren vorstellen kann, finden Sie hier nur eine Auswahl von Prozeduren. <\/p>\n Die API-Funktionen zur Bestimmung des Computernamens und des aktuellen Benutzers des Computers sollen als erstes Beispiel dienen. Die entsprechenden API-Prozeduren heißen GetComputerName <\/b>und GetUserName<\/b>.<\/p>\n <\/p>\n Sie müssen die Prozeduren vor dem Aufruf in geeigneter Weise deklarieren. Damit Sie die im Rahmen des vorliegenden Beitrags erstellten Prozeduren mit ihren API-Aufrufen gut in Ihre eigenen Datenbanklösungen integrieren können, legen Sie jeweils ein neues Modul für jedes Beispiel an.<\/p>\n Wenn Sie ein neues Standardmodul angelegt haben, speichern Sie es unter dem Namen mdlSystemInformation<\/b>. Anschließend deklarieren Sie die erste der beiden Funktionen wie folgt:<\/p>\n Der Deklaration können Sie entnehmen, dass die Funktion GetComputerName <\/b>zur Dynamic Link Library Kernel32 <\/b>gehört und dort unter dem Namen GetComputerNameA <\/b>bekannt ist. Die Funktion hat zwei Parameter, die Zeichenkette lpBuffer <\/b>wird als Wert übergeben, während die Länge der Zeichenkette nSize <\/b>als Referenz übergeben wird. Der Rückgabewert hat den Datentyp Long<\/b>.<\/p>\n Der Rückgabewert enthält bei vielen Funktionen nicht die Informationen, die Sie eigentlich abrufen möchten. In der vorliegenden Funktion GetComputerName <\/b>wird etwa der Zahlenwert 1 <\/b>zurückgegeben, wenn es einen Computernamen gibt, und der Wert 0<\/b>, wenn kein Computername gefunden wurde. <\/p>\n Die gewünschte Information packt die API-Funktion in die Parameter. Sie weist dem Parameter lpBuffer <\/b>den Namen des Computers als String und dem Parameter nSize <\/b>die Länge der übergebenen Zeichenkette als Long <\/b>zu.<\/p>\n Es ist sehr wichtig, dass Sie String<\/b>-Parametern vor der übergabe an eine DLL eine Zeichenkette zuweisen, die mehr Zeichen enthält als der erwartete Wert haben kann. Ist der zurückgegebene String länger als der übergebene String, löst das einen Fehler aus.<\/p>\n In der Funktion aus Listing 1 können Sie die API-Funktion nun endlich einsetzen.<\/p>\n Listing 1: Funktion zum Ermitteln des Computernamens per API<\/span><\/b><\/p>\n Zunächst deklarieren Sie dort die benötigten Variablen für den zu übergebenden Text sowie die Länge des Textes.<\/p>\n Der Variablen lngTemp <\/b>weisen Sie den Rückgabewert der Funktion zu. Dem Parameter strComputerName <\/b>weisen Sie mit der Space$<\/b>-Funktion einen String mit 256 Leerzeichen zu. Nach dem Aufruf der Funktion benutzen Sie die Funktion Trim$<\/b>, um die überflüssigen Leerzeichen des zurückgegebenen Wertes zu entfernen.<\/p>\n Testen Sie die Funktion mit Hilfe des Testfenster (zu öffnen mit Strg + G<\/b>). Lassen Sie sich einfach den Computernamen in einem Meldungsfenster ausgeben:<\/p>\n Die Ausgabe des Benutzernamens können Sie in ähnlicher Weise vornehmen. Die Deklaration des entsprechenden API-Aufrufs lautet:<\/p>\n Die Vorgehensweise zum Ermitteln des Namens des aktuell eingeloggten Benutzers ist prinzipiell mit dem Ermitteln des Computernamens identisch. Die Funktion zum Aufruf der API-Prozedur GetUserNameA <\/b>ist allerdings etwas anders gestaltet, um Sie auf eine Besonderheit beim Aufruf von API-Funktionen aufmerksam zu machen (s. Listing 2).<\/p>\n Listing 2: Funktion zum Ermitteln des Benutzernamens per API<\/span><\/b><\/p>\n Wie Sie erkennen können, gibt es in der Funktion keine Variable namens lngTemp<\/b>, um den Rückgabewert der API-Funktion zu speichern. Die Funktion wird auch gar nicht in Form einer Wertzuweisung aufgerufen, wie es üblicherweise bei Funktionen der Fall ist, sondern wie eine Prozedur. Da es in den meisten Fällen nicht auf den Rückgabewert ankommt, sondern auf die geänderten Parameter, kann man sich hier die Deklaration einer Variablen und damit Zeit und Speicherplatz sparen.<\/p>\n Die beiden Funktionen können Sie nun zum Beispiel benutzen, um den Anwender beim Start der Datenbank mit seinem Namen zu begrüßen.<\/p>\n Den Begriff Handle <\/b>werden Sie sicher bereits einmal gehört haben. Ein Handle ist eine Möglichkeit, Objekte unter Windows eindeutig zu kennzeichnen. Dadurch, dass Windows mitunter Objekte aus dem Arbeitsspeicher temporär auf die Festplatte oder in andere Speicherbereiche verbannt, sind die Objekte teilweise nicht mehr unter der angegebenen Speicheradresse anzutreffen.<\/p>\n Dies erscheint zunächst wie ein Windows-internes Problem – da Sie aber per API Windows direkt steuern, erweisen sich Handles für den Entwickler als sehr nützlich. Der Inhalt eines Handles, also der Verweis auf ein Objekt, wird immer im Arbeitsspeicher gehalten – auch wenn das Objekt selbst zwischenzeitlich auf die Festplatte verbannt wurde.<\/p>\n Wenn Sie also per API auf ein Objekt zugreifen möchten, ermitteln Sie zunächst dessen Handle. Zur Ermittlung eines Handles gibt es unterschiedliche Möglichkeiten, von denen einige später vorgestellt werden. Wenn Sie das Handle einmal kennen, können Sie über das Handle auf das entsprechende Objekt zugreifen. <\/p>\n Deutlicher wird dies an einem Beispiel. Mit der Funktion GetWindowText <\/b>soll der Titel des aktuellen Access-Hauptfensters ermittelt werden. Die API-Prozedur hat die folgende Deklaration:<\/p>\n Der erste Eintrag in der Parameterliste ist der Parameter hWnd<\/b>. Für ihn müssen Sie das Handle des Fensters übergeben, dessen Fenstertext Sie ermitteln möchten. Sie müssen also zunächst das Handle bestimmen. Wenn Sie die Funktion von Access aus aufrufen, ist das gewünschte Fenster das aktuelle Fenster. Das Handle des aktuellen Fensters ermitteln Sie mit der wie folgt deklarierten API-Prozedur:<\/p>\n Sie können nun beide API-Funktionen in einer Funktion verwenden (s. Listing 3).<\/p>\n Listing 3: Funktion zum Ermitteln des Fenstertitels des aktiven Fensters<\/span><\/b><\/p>\n Die Funktion FenstertitelErmitteln <\/b>legt wie gewohnt zunächst die an die API-Funktion zu übergebenden Parameter fest. Dabei wird das Handle auf das aktuelle Fenster ebenfalls durch eine API-Funktion ermittelt und anschließend weiterverwendet. Im Direktbereich liefert der Funktionsaufruf das folgende Ergebnis:<\/p>\n Sie können Funktionsnamen der bisher erstellten Funktionen in einem Formular als Steuerelementinhalt verschiedener Textfelder angeben (s. Bild 2).<\/p>\n Bild 2: VBA-Funktionen im Formular nutzen (Entwurf)<\/span><\/b><\/p>\n Die Textfelder geben dann die Ergebnisse der Funktion aus (s. Bild 3).<\/p>\n Bild 3: VBA-Funktionen im Formular nutzen (Formularansicht)<\/span><\/b><\/p>\n Wenn Sie später weitere API-Funktionen verwenden, werden Sie des öfteren mit Handles arbeiten müssen. Parameter, die ein Handle als Wert erwarten, beginnen immer mit einem kleinen h <\/b>und enden mit dem Typ des Handles. In der folgenden Auflistung finden Sie einige Beispiele von Handles (Parametername in Klammern):<\/p>\n Sie können das Handle des Access-Hauptfensters auch auslesen, wenn es nicht das aktive Fenster ist. Dabei handelt es sich allerdings nicht um eine API-Prozedur, sondern um eine Access-interne Funktion. Die Funktion lautet:<\/p>\n Wenn Sie für eine eigene Datenbankanwendung einen eigenen Fenstertitel angeben möchten, können Sie das auch mit einer API-Funktion tun:<\/p>\n Zur Anzeige eines alternativen Fenstertitels benutzen Sie den folgenden Befehl (in neuen Access-Versionen erscheint dieser Titel jedoch nur in der Taskleiste):<\/p>\n Im vorliegenden Fall geben Sie die Parameter direkt an. Das ist eine gute Möglichkeit, eine API-Funktion im Testfenster auszuprobieren. Achtung: Wenn Sie Zeichenfolgen an API-Funktionen übergeben, bei denen Sie die Länge der Zeichenfolge nicht angeben können, fügen Sie der Zeichenfolge immer den Wert & vbNullChar <\/b>an. Nur so kann die API-Funktion erkennen, dass die Zeichenkette zu Ende ist.<\/p>\n Bei manchen Anwendungen soll aus optischen Gründen das aktuelle Formular das ganze Access-Hauptfenster ausfüllen. Access bietet zwar Befehle, mit denen das aktuelle Formular maximiert, minimiert oder wiederhergestellt werden kann. Sie können aber nicht feststellen, welchen Zustand das Formular momentan hat. In den folgenden Abschnitten schauen wir uns an, wie Sie dies erledigen können.<\/p>\n Das Handle eines Formulars können Sie über die Formulareigenschaft hWnd <\/b>ermitteln. Um etwa das Handle eines Formulars mit dem Namen frmAPI <\/b>herauszufinden, benutzen Sie die folgende Anweisung (hier zur Ausgabe im Direktbereich):<\/p>\n Wenn Sie das Handle des Formulars kennen, können Sie leicht den Status des Formulars herausfinden.<\/p>\n Deklarieren Sie dazu die beiden folgenden API-Prozeduren:<\/p>\n Definieren Sie außerdem die folgenden Konstanten im Deklarationsteil des Moduls:<\/p>\n Die Funktion Fensterzustand <\/b>schließlich ermittelt mit Hilfe der beiden Funktionen IsIconic <\/b>und IsZoomed<\/b>, ob das Fenster minimiert oder maximiert ist. Falls keiner der beiden Fälle eintritt, bleibt nur noch der „normale“ Zustand des Fensters:<\/p>\n Falls der Anwender ein bestimmtes Formular minimiert hat, das zu einem bestimmten Zeitpunkt sichtbar sein soll, können Sie das überprüfen und das Fenster gegebenenfalls in den gewünschten Zustand bringen. Den Zustand eines Formulars ermitteln Sie etwa mit folgender Anweisung:<\/p>\n Die Ergebniswerte entsprechen dabei den Werten der soeben deklarierten Konstanten: 0 <\/b>für den normalen Zustand, 1 <\/b>für ein maximiertes und 2 <\/b>für ein minimiertes Formular.<\/p>\n Mit der gleichen Funktion können Sie natürlich auch den Status des Access-Hauptfensters ermitteln. Sie müssen der Funktion lediglich das Handle des Access-Fensters übergeben, also etwa folgendermaßen:<\/p>\n Dazu benötigen Sie insgesamt drei Funktionen. Zunächst legen Sie mit der Funktion CreateIC <\/b>das Gerät fest, über das Sie Informationen erhalten möchten – in diesem Fall der Monitor. Es handelt sich dabei um die schnellste Möglichkeit, Informationen über ein bestimmtes Gerät zu erhalten. Die Deklaration der Funktion lautet:<\/p>\n Nach der Abfrage der gewünschten Informationen müssen Sie die Verbindung zu den Informationen wieder löschen. Das geschieht mit der Funktion DeleteIC <\/b>mit folgender Deklaration:<\/p>\n Natürlich müssen Sie auch noch die gesuchten Informationen abrufen. Dazu dient die Funktion GetDeviceCaps<\/b>:<\/p>\n Schließlich benötigen Sie noch eine benutzerdefinierte Funktion, die auf die genannten API-Funktionen zurückgreift, um die Bildschirmauflösung zu ermitteln.<\/p>\n In der Funktion aus Listing 4 legen Sie zunächst eine Variable für das Handle fest, das auf den Gerätekontext des Bildschirms verweist. Anschließend deklarieren Sie einige Konstanten, die von der API-Funktion CreateIC <\/b>zum Setzen des Handles auf den Gerätekontext des Monitors benötigt werden.<\/p>\n Listing 4: Funktion zum Ermitteln der Bildschirmauflösung<\/span><\/b><\/p>\n Neben dem Monitor können Sie so auch auf die Informationen des Gerätekontext von Druckern zugreifen. Da an den meisten Rechnern nur ein Monitor angeschlossen ist, reicht die Angabe des Wertes Display<\/b> für die Konstante DRIVER_NAME<\/b>. Wenn Sie Informationen über einen Drucker erhalten möchten, müssen Sie weitere Angaben wie zum Beispiel zum Druckernamen machen. Geben Sie dazu den Druckernamen an, der im Drucken<\/b>-Dialog angezeigt wird.<\/p>\n Nach dem Setzen des Verweises auf den Bildschirmkontext fragen Sie mit der API-Funktion GetDeviceCap <\/b>die gewünschte Eigenschaft ab. Da Sie nur eine Eigenschaft gleichzeitig abfragen können, rufen Sie die Funktion für die horizontale und vertikale Auflösung zwei Mal auf.<\/p>\n Schließlich heben Sie den Verweis auf den Gerätekontext wieder auf.<\/p>\n Damit Sie die Funktion anwenden können, deklarieren Sie noch zwei globale Konstanten:<\/p>\n Wenn Sie die Funktion nun aufrufen, müssen Sie nicht mit den Zahlenwerten der gesuchten Eigenschaften arbeiten, sondern können die aussagekräftigeren Konstantennamen verwenden. Die folgende Funktion gibt in einem Meldungsfenster die aktuelle Bildschirmauflösung aus (s. Bild 4):<\/p>\n Bild 4: Ausgabe der Bildschirmauflösung<\/span><\/b><\/p>\n Für manche Anwendungen ist es sinnvoll, das Access-Hauptfenster in einer bestimmten Größe anzuzeigen. Das kann zum Beispiel den Grund haben, dass die Formulare für eine bestimmte Bildschirmgröße optimiert sind und in einem maximierten Hauptfenster auf einem 27“-Monitor etwas verloren wirken. Bei Formularen ist das kein Problem: Sie müssen einfach beim öffnen des Formulars den Eigenschaften Links<\/b>, Rechts<\/b>, Höhe <\/b>und Breite <\/b>die gewünschten Eigenschaften zuweisen.<\/p>\n Außerdem können Sie mit der Eigenschaft Zentriert <\/b>angeben, ob das Formular im Hauptfenster zentriert angezeigt werden soll. Selbst wenn der Benutzer die Koordinaten während der Benutzung des Formulars verändert, könnten Sie beim Schließen die aktuellen Werte in einer Tabelle abspeichern und sie beim erneuten öffnen des Formulars erneut abrufen.<\/p>\n Beim Access-Hauptfenster können Sie die Aufgabe nur mit API-Funktionen erledigen. Mit der folgenden API-Funktion können Sie die Position und die Größe des Anwendungsfensters sowie einige andere Eigenschaften ändern.<\/p>\n Dazu gehört die Reihenfolge in der Liste der Fenster sowie einige Zeiger, mit denen Sie das Fenster zum Beispiel in den Hintergrund verschieben oder deaktivieren können. Hier geht es aber vordergründig um die Position und die Größe des Fensters.<\/p>\n Die Parameter x <\/b>und y <\/b>legen die Position der oberen, linken Ecke des Fensters fest, die Parameter cx <\/b>und cy <\/b>die Breite und die Höhe des Fensters. Wenn Sie etwa möchten, dass das Hauptfenster bei jeder Bildschirmgröße zentriert mit 800 x 600 Pixeln angezeigt wird, müssen Sie das dem System nur per API-Funktion mitteilen.<\/p>\n Außerdem benötigen wir noch zwei Konstanten, die wir im Kopf des Standardmoduls deklarieren:<\/p>\n Zunächst ermitteln Sie mit der Funktion Bildschirmaufloesung() <\/b>die aktuelle Auflösung.<\/p>\n Anschließend ist ein wenig Mathematik gefragt: Sie wissen zwar, dass Ihr Hauptformular mit 800 mal 600 Bildpunkten angezeigt werden soll. Sie müssen allerdings die Koordinaten noch so berechnen, dass das Hauptfenster auch zentriert angezeigt wird. Bild 5 zeigt die Lage der einzelnen Maße.<\/p>\n Bild 5: Koordinaten von Bildschirm und Fenster<\/span><\/b><\/p>\n Die x-Komponente wird berechnet aus:<\/p>\n Die Berechnung der y-Komponente erfolgt analog:<\/p>\n In der Funktion aus Listing 5 sind die entsprechenden Berechnungen untergebracht. Als Parameter übergeben Sie der Funktion die gewünschte Auflösung.<\/p>\nSyntax der Deklaration einer API-Prozedur<\/h2>\n
[Public|Private] Declare Function|Sub name Lib \"libname\" _ [Alias \"aliasname\"]([argumentlist])] [As type] <\/pre>\n
\n
Datentypen beim Aufruf von API-Prozeduren<\/h2>\n
Wo deklariere ich API-Prozeduren<\/h2>\n
Praxisbeispiele zur Benutzung der Windows-API mit Access<\/h2>\n
Name des Computers und des Benutzers ermitteln<\/h2>\n
Declare Function GetComputerName Lib \"kernel32\" _\r\n Alias \"GetComputerNameA\" (ByVal lpBuffer As <\/span>_\r\n String, nSize As Long<\/span>) As Long<\/span><\/pre>\nPublic Function <\/span>Computername() As String<\/span>\r\n Dim <\/span>strComputerName As String<\/span>\r\n Dim <\/span>lngAnzahlZeichen As Long<\/span>\r\n Dim <\/span>lngTemp As Long<\/span>\r\n lngAnzahlZeichen = 256\r\n strComputerName = Space$(lngAnzahlZeichen)\r\n lngTemp = GetComputerName(strComputerName, lngAnzahlZeichen)\r\n Computername = Trim$(strComputerName)\r\nEnd Function<\/span><\/pre>\n Computername\r\nWIN7OFF13IND <\/pre>\n
Benutzername per API ermitteln<\/h2>\n
Declare Function GetUserName Lib \"advapi32.dll\" _\r\n Alias \"GetUserNameA\" (ByVal lpBuffer As String<\/span>, _\r\n nSize As Long<\/span>) As Long<\/span><\/pre>\nPublic Function <\/span>Benutzername() As String<\/span>\r\n Dim <\/span>strBenutzername As String<\/span>\r\n Dim <\/span>lngAnzahlZeichen As Long<\/span>\r\n lngAnzahlZeichen = 256\r\n strBenutzername = Space$(lngAnzahlZeichen)\r\n GetUserName strBenutzername, lngAnzahlZeichen\r\n Benutzername = Trim$(strBenutzername)\r\nEnd Function<\/span><\/pre>\nZugriff auf Fenster und andere Objekte per Handle<\/h2>\n
Declare Function GetWindowText Lib \"user32\" Alias _\r\n \"GetWindowTextA\" (ByVal hWnd As Long<\/span>, ByVal _\r\n lpString As String<\/span>, ByVal cch As Long<\/span>) As Long<\/span><\/pre>\nDeclare Function GetActiveWindow Lib \"user32\" () As Long<\/span><\/pre>\nPublic Function <\/span>FenstertitelErmitteln()\r\n Dim <\/span>hWnd As Long<\/span>\r\n Dim <\/span>strFenstertitel As String<\/span>\r\n Dim <\/span>lngAnzahlZeichen As Integer<\/span>\r\n lngAnzahlZeichen = 256\r\n strFenstertitel = Space$(lngAnzahlZeichen)\r\n hWnd = GetActiveWindow()\r\n GetWindowText hWnd, strFenstertitel, 255\r\n FenstertitelErmitteln = Left$(strFenstertitel, lngAnzahlZeichen)\r\nEnd Function<\/span><\/pre>\n FenstertitelErmitteln\r\nMicrosoft Visual Basic for Applications - API [Aktiv] - [mdlSystemInformation (Code)]<\/pre>\n
![\"VBA-Funktionen](\"..\/fileadmin\/_temp_\/2016_02\/pic_1032_001.png\")
<\/p>\n![\"VBA-Funktionen](\"..\/fileadmin\/_temp_\/2016_02\/pic_1032_002.png\")
<\/p>\n\n
Application.hWndAccessApp<\/pre>\n
Declare Function SetWindowText Lib \"user32\" Alias _\r\n \"SetWindowTextA\" (ByVal hWnd As Long<\/span>, _\r\n ByVal lpString As String<\/span>) As Long<\/span><\/pre>\nSetWindowText Application.hWndAccessApp,\"Neuer Titel\"<\/pre>\n
Zustand eines Formulars ermitteln<\/h2>\n
Handle eines Formulars ermitteln<\/h2>\n
Forms!frmAPI.hWnd\r\n 593800 <\/pre>\n
Status eines Formulars ermitteln<\/h2>\n
Declare Function IsIconic Lib \"user32\" _\r\n (ByVal hWnd As Long<\/span>) As Long<\/span>\r\nDeclare Function IsZoomed Lib \"user32\" _\r\n (ByVal hWnd As Long<\/span>) As Long<\/span><\/pre>\nGlobal Const NORMAL = 0\r\nGlobal Const MAXIMIZED = 1\r\nGlobal Const MINIMIZED = 2<\/pre>\n
Function <\/span>Fensterzustand(ByVal hWnd As Long<\/span>) As Integer<\/span>\r\n If <\/span>IsIconic(hWnd) Then<\/span>\r\n Fensterzustand = MINIMIZED\r\n Exit Function<\/span>\r\n End If<\/span>\r\n If <\/span>IsZoomed(hWnd) Then<\/span>\r\n Fensterzustand = MAXIMIZED\r\n Exit Function<\/span>\r\n End If<\/span>\r\n Fensterzustand = NORMAL\r\nEnd Function<\/span><\/pre>\n Fensterzustand(forms!frmAPi.hWnd)\r\n 0<\/pre>\n
Status des Access-Hauptfensters ermitteln<\/h2>\n
Fensterzustand(Application.hWndAccessApp)<\/pre>\n
Bildschirmauflösung ermitteln<\/h2>\n
Private <\/span>Declare Function CreateIC Lib \"gdi32\" Alias _\r\n \"CreateICA\" (ByVal lpDriverName As String<\/span>, ByVal _\r\n lpDeviceName As <\/span>Any, ByVal lpOutput As <\/span>Any, ByVal _\r\n lpInitData As <\/span>Any) As Long<\/span><\/pre>\nPrivate <\/span>Declare Function DeleteDC Lib \"gdi32\" _\r\n (ByVal hdc As Long<\/span>) As Long<\/span><\/pre>\nPrivate <\/span>Declare Function GetDeviceCaps Lib \"gdi32\" _\r\n (ByVal hdc As Long<\/span>, ByVal nIndex As Long<\/span>) As Long<\/span><\/pre>\nPublic Function <\/span>Bildschirmaufloesung(ByVal Eigenschaft As Integer<\/span>) As Integer<\/span>\r\n Dim <\/span>hDC As Long<\/span>\r\n Const DRIVER_NAME = \"DISPLAY\"\r\n Const DEVICE_NAME = 0&\r\n Const OUTPUT_DEVICE = 0&\r\n Const lpDevMode = 0&\r\n hDC = CreateIC(DRIVER_NAME, DEVICE_NAME, OUTPUT_DEVICE, lpDevMode)\r\n If <\/span>hDC Then<\/span>\r\n Bildschirmaufloesung = GetDeviceCaps(hDC, Eigenschaft)\r\n DeleteDC hDC\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nPublic <\/span>Const HORZRES = 8\r\nPublic <\/span>Const VERTRES = 10<\/pre>\n![\"Ausgabe](\"..\/fileadmin\/_temp_\/2016_02\/pic_1032_003.png\")
<\/p>\nMsgBox<\/span> \"Die Bildschirmauflösung beträgt derzeit \" _\r\n & Bildschirmaufloesung(HORZRES) & \" x \" _\r\n & Bildschirmaufloesung(VERTRES) & \" Pixel.\"<\/pre>\nGröße und Lage des Access-Hauptfensters <\/h2>\n
Declare Function SetWindowPos Lib \"user32\" (ByVal hWnd _\r\n As Long<\/span>, ByVal hWndInsertAfter As Long<\/span>, ByVal x As <\/span>_\r\n Long, ByVal y As Long<\/span>, ByVal cx As Long<\/span>, ByVal cy _\r\n As Long<\/span>, ByVal wFlags As Long<\/span>) As Long<\/span><\/pre>\nPublic <\/span>Const HWND_TOP = 0\r\nPublic <\/span>Const SWP_NOZORDER = 4<\/pre>\n![\"Koordinaten](\"..\/fileadmin\/_temp_\/2016_02\/pic_1032_005.png\")
<\/p>\nx = (HORZRES - cx) \/ 2<\/pre>\n
y = (VERTRES - cy) \/ 2<\/pre>\n
Function <\/span>HauptfensterZentrieren(cx As Integer<\/span>, cy As Integer<\/span>)\r\n Dim <\/span>x As Integer<\/span>\r\n Dim <\/span>y As Integer<\/span>\r\n x = (Bildschirmaufloesung(HORZRES) - cx) \/ 2\r\n y = (Bildschirmaufloesung(VERTRES) - cy) \/ 2\r\n SetWindowPos Application.hWndAccessApp, HWND_TOP, x, y, cx, cy, SWP_NOZORDER\r\nEnd Function<\/span><\/pre>\n