VisualBasic.tips

Fensterhandling per API

veröffentlicht: redmond's inside ACCESS, Ausgabe 05/2001

Download Beispieldatei

Welcher Access-Programmierer kennt das Problem des eigensinnigen Fensterhandling in Acces nicht? Wird ein Fenster maximiert dargestellt, tun es ihm die übrigen Fenster gleich. Die Möglichkeiten ein Formular als Dialog zu öffnen, hat den Haken, dass eventuell ausgeführter Programmcode angehalten wird. Und die Popup-Eigenschaft ist auch nicht immer die passende Lösung. Außerdem gibt es diese Möglichkeiten nur für Formulare, bei Berichten muss trotzdem auf die  Maximize- bzw. Restore-Methode des DoCmd-Befehls zurückgegriffen werden. Warum gibt es in Access keine Möglichkeit die Fensterdarstellung umfassender zu manipulieren? Es gibt Eine, allerdings nur mit Hilfe von API-Funktionen. Zugegeben, nicht die leichteste Kost, aber die Mühe lohnt sich. Dieser Artikel stellt ihnen vier API-Funktionen zum ultimativen Fensterhandling auch in Access vor.

Grundsätzliches zu API

API steht für Application Programming Interface, was soviel heißt wie Programmierschnittstelle für Anwendungen. API´s sind Funktionen, die in DLL-Dateien (den Dynamic-Link Libraries) zusammengefasst wurden und das Rückrat von Microsoft Windows bilden. Unzählige Programme greifen auf diese Funktionen zurück, Wiederverwendbarkeit pur. Die API´s bieten Funktionen, die über den Sprachkern vieler Entwicklungsumgebungen hinaus gehen, zum Beispiel systemnahe Funktionen, wie die Speicherverwaltung oder eben das Fensterhandling. Im System-Verzeichnis von Windows gibt es eine große Anzahl DLL-Dateien, wobei die Kernel32.dll, die User32.dll, die OLE32.dll und die Shell32.dll die Wichtigsten sein dürften. Fehlt auch nur eine dieser Dateien würde Windows, wenn überhaupt, nur noch extrem eingeschränkt funktionieren.

Die DLL´s sind genauso aufgebaut wie Access-Module Im Kopf stehen die Type-Variablen, Kostanten und Variablen, gefolgt von den eigentlichen Funktionen und Prozeduren.

Weil die Funktionen der DLL-Dateien mit herkömmlichen Mitteln nicht betrachtet werden können, gibt es dazu ein kleines Programm, den API-Viewer (siehe Kasten).

((KASTEN ANFANG))

API-Viewer

Der API-Viewer ist im Lieferungsumfang vieler Entwicklungsumgebungen enthalten, so auch in der Microsoft Office Developer Edition. Der API-Viewer kann Text- und Datenbankdateien mit Informationen zu DLL-Dateien laden und anzeigen. Leider kann auch dieses Tool nicht direkt auf die DLL´s zugreifen und deren Inhalt darstellen. Dazu braucht es spezielle Dateien, die beim Setup mit installiert werden. Es gibt mehrere Varianten des API-Viewers, Abbildung 1 zeigt diejenige von Office 97. Über das DropDown-Steuerelement kann zwischen den Abschnitten Deklarationen, Typen und Konstanten gewechselt werden. Durch Doppelklick auf entsprechende Einträge der oberen Liste werden die Deklarationen in das Feld ausgewählte Elemente kopieren. Dieser Vorgang kann beliebig oft wiederholt werden. Am Ende kopiert man den kompletten Inhalt über die Schaltfläche [kopieren] in die Zwischenablage und von dort an jede beliebige Stelle.

((KASTEN ENDE))

Abbildung 1: API-Viewer aus Office 97 DE

API-Funktionen nutzbar machen

Im Listing 1 sehen Sie den Inhalt eines globalen Moduls, in dem einige API-Deklarationen vorgenommen wurden. Um API-Funktionen zu nutzen, müssen Sie Access mitteilen, wo sich die Funktion befindet. Zu diesem Zweck verwendet man die Declare-Anweisung. Ein Beispiel:

Public _
Declare _
Function Get-Window-Placement _
Lib "user32.dll" _
Alias GetWindowPlacement _
(ByVal hwnd As Long, _
       lpwndpl As WINDOWPLACEMENT) As Long

Sehen sie die Declare-Anweisung als das an was sie ist, ein Funktions-Deklaration. Denken Sie sich die Zeilen Declare, Lib und Alias weg und schon haben sie eine ganz normalen Funktionskopf, nur eben ohne den Rumpf, der steht in der DLL-Datei. Access weiß durch die Anweisung wo es die Prozedur im Bedarfsfall suchen muss, das heißt sie können auf die API zugreifen, wie auf eine herkömmliche Access-Prozedur.

Übersetzt könnte die Zeile lauten: öffentliche Erklärung der Funktion Get-Window-Placement in der Bibliothek User32.dll, im Folgenden GetWindowPlacement genannt, mit den Parametern xxx.

Der Alias-Abschnitt findet eigentlich nur dann Verwendung wenn der Funktionsname ungültige Zeichen verwendet. Es gibt leider keinen Zeichen-Standard an den sich alle Hersteller von Entwicklungssoftware halten.  In Access zum Bespiel darf im Prozedurnamen kein Bindestrich verwendet werden.
Im Lib-Abschnitt muss keine Pfadangabe gemacht werden, da die Datei zwingend im System-Verzeichnis stehen muss. Die Dateiendung ist auch nicht unbedingt erforderlich. Die Praxis hat allerdings das Gegenteil gezeigt. Ohne die Endung funktioniert es in der Regel nicht.

Unser Beispiel übergibt zwei Parameter, wobei der Zweite vom Datentyp Type ist. Type-Variablen sind in der Regel benutzerdefiniert. Bevor eine Type-Variable verwendet werden darf, muss sie dem Programm bekannt sein. Das bedeutet, dass die Definition der Type-Variablen vor dem Deklarations-Abschnitt der API-Funktionen erfolgen muss (siehe Listing 1). Access arbeitet die Module immer von oben nach unten ab. Auch die Type-Variable verwendet ihrerseits Type-Variablen (POINTAPI, RECT), die ebenfalls schon definiert sein müssen.

Type POINTAPI
   x As Long
   y As Long
End Type

Type WINDOWPLACEMENT
   Length As Long
   Flags As Long
   showCmd As Long
   ptMinPosition As POINTAPI
   ptMaxPosition As POINTAPI
   rcNormalPosition As RECT
End Type

Unterhalb des API-Deklarations-Abschnitts (Listing 1) sind ein Vielzahl von Konstanten definiert. Sehr viele Parameter der DLL-Funktionen erwarten als Übergabewert eine Konstante, wobei der Umfang der akzeptierten Werte meist beschränkt ist. Die Kostantennamen repräsentieren oft Einstellungen, ähnlich den Auswahllisten im Eigenschaftenfenster. Die Konstanten müssen nicht unbedingt deklariert werden, was aber angesichts der Vielfalt bestimmt sinnvoll ist. Außerdem erhöht sich die Lesbarkeit durch die Verwendung von eigenen Konstantennamen. Sie können die Originalnamen zwar dem API-Viewer entnehmen, zu diesem Zweck müssen sie ihnen allerdings erst bekannt sein, ansonsten brauchte man viel Transferphantasie. Um den Konstantenumfang komfortabel zu ermitteln, ist es hilfreich im Besitz einer MSDN Library zu sein. Dort sind die API-Funktionen und ihre Konstanten detailliert beschrieben.

Die API-Funktionen zum ultimativen Fensterhandling

Es gibt zwei API-Funktionen zur Ermittlung der Fensterposition, die GetWindowPlacement- und die GetWindowRect-Funktion. Wobei man die Zweite als abgespeckte Version der Ersten ansehen könnte. Die Funktion GetWindowRect ermittelt nur die Koordinaten des übergebenen Fensters. Das macht auch die GetWindowPlacement-Funktion, darüber hinaus gibt sie die Darstellungsart des Fensters zurück, zum Bespiel ob es minimiert, maximiert, als Fenster oder versteckt. angezeigt wird.

Die GetWindowsRect-Funktion gibt einen Parameter vom Typ RECT zurück:

Type RECT
   left As Long
   top As Long
   right As Long
   bottom As Long
End Type

Public Declare _
Function GetWindowRect _
Lib "user32.dll" _
(ByVal hwnd As Long, _
       lpRect As RECT) As Long

Die Type-Variable beinhaltet ihrerseits Variablen, welche die Koordinaten für die Punkte links oben (left, top) und rechts unten (right, bottom) eines Fenster repräsentieren. Von welchem Fenster, wird der Funktion durch den Parameter hwnd mitgeteilt. Die Variable erwartet den Zahlencode des aktuellen Handlings eines Fensters. Jedes Window erhält bei seiner Erstellung einen sogenannten Handle (sprich händl). Dabei handelt es sich um eine Zufallszahl als eindeutigen Index für alle geöffnete Fenster. Über diesen Handle kann auf jedes beliebige Fenster anwendungsübergreifend zugegriffen werden.

Um die Koordinaten eines Fenster zu ermitteln muss beim Aufruf der Funktion das Fensterhandle und eine (leere) Variable vom Typ RECT mitgegeben werden. Die Funktion sucht das Fenster, ermittelt seine Koordinaten und schreibt sie in den Inhalt der (leeren) RECT-Variablen. Diese kann dann im folgenden Code weiterverwendet bzw. ausgewertet werden:

Private Sub btn_GetWinRect_Click()
   Dim v_Rect As RECT
   Call GetWindowRect(hwnd:=Me.hwnd, lpRect:=v_Rect)
   MsgBox "x1: " & v_Rect.Left & " - y1: " & v_Rect.top & vbNewLine & _
          "x2: " & v_Rect.Right & " - y2: " & v_Rect.bottom & vbNewLine
End Sub

Anmerkung:

Die Rückgabe der Koordinaten entspricht den Pixel auf dem Bildschirm. Access verwendet aber die Einheit Twips, wobei 1 mm  genau 56.7 Twips entsprechen. 1 Pixel sind umgerechnet 15 Twips.

Die API-Funktion GetWindowsPlacement

Die Funktion GetWindowsPlacement ist etwas leistungsfähiger und deshalb auch komplizierter in der Anwendung. Auch diese Funktion benötigt zwei Parameter, und auch hier liefert der Zweite mehrere Daten als Rückgabewerte zurück, zusammengefasst in der Type-Variablen WindowPlacement, wobei nicht alle Rückgabewerte relevant sind. Der  volle Umfang des WindowPlacement-Typs wird erst bei der SetWindowPlacement-Funktion genutzt.

Type WINDOWPLACEMENT
   Length As Long
   Flags As Long
   showCmd As Long
   ptMinPosition As POINTAPI
   ptMaxPosition As POINTAPI
   rcNormalPosition As RECT
End Type

Die Length-Variable des WindowPlacement spielt bei der Verwendung eine zentrale Rolle. Diese Variable muss vor der Nutzung der Funktion initialisiert sein. Und zwar mit der Anzahl an Bytes, die zum Speichern der WindowsPlacement-Variable erforderlich sind. .... Lassen Sie das mal eine Weile auf sich wirken und nehmen sie es einfach so hin, das ist „höhere“ C-Programmierung. Das Setzen der Variable sieht folgendermaßen aus:

Dim hdl_Window As WINDOWPLACEMENT
hdl_Window.Length = Len(hdl_Window)

Sie deklarieren eine Variable vom WindowPlacement-Typ und weisen dessen Length-Eigenschaft  per Len-Funktion (oder LenB) die Länge seiner eigenen Byte-Struktur zu. Ohne diesen Schritt funktioniert die API leider nicht.

Im Listing 2 können sie das Beispiel anhand der Funktionen Get_WinPlace und Set_WinPlace im Kontext nachvollziehen.

Die showCmd-Variable des WindowsPlacement-Type ist ohne Zweifel die Interessanteste. Mit ihr kann der Anzeigezustand eines Fenster ermittelt werden (API-Funktion GetWindowPlacement) oder gesetzt werden (SetWindowPlacement). In der folgenden Tabelle erhalten sie einen Überblick über die Zustände, die showCmd annehmen beziehungsweise durch sie gesetzt werden kann.

Tabelle 1: Werte der showCmd-Variable

Konstante	Wert	Beschreibung
SW_HIDE	0	Fenster verstecken (Fokus wechselt)
SW_MINIMIZE	6	Fenster minimieren (Fokus wechselt)
SW_RESTORE	9	Fenster wiederherstellen (Originalzustand)
SW_SHOW	5	Fenster anzeigen (wenn minimiert oder maximiert dann wiederherstellen)
SW_SHOWMAXIMIZED	3	Fenster aktivieren und maximieren
SW_SHOWMINIMIZED	2	Fenster aktivieren und minimieren
SW_SHOWMINNOACTIVE	7	Fenster minimieren (aktives Fenster bleibt aktiv)
SW_SHOWNA	8	Fenster im aktuellen Zustand anzeigen (aktives Fenster bleibt aktiv)
SW_SHOWNOACTIVATE	4	Fenster in seinem letzten Zustand anzeigen (aktives Fenster bleibt aktiv)
SW_SHOWNORMAL	1	Wie SW_SHOW

Die API-Funktion SetWindowPos

Während man mit der Funktion SetWindowPlacement sehr gut den Anzeigestatus eines Fensters manipulieren kann, eignet sich die SetWindowPos-API hervorragend zur Veränderung der Größe, der Position und der Aktivierreihenfolge im Stapel sich überlappender Fenster (Z order).

Public Declare _
Function SetWindowPos _
Lib "user32.dll"
 (ByVal hwnd As Long, _
  ByVal hWndInsertAfter As Long, _
  ByVal x As Long, _
  ByVal y As Long, _
  ByVal cx As Long, _
  ByVal cy As Long, _
  ByVal wFlags As Long) As Long

Die Funktion verarbeitet neben dem Fensterhandle (hwnd) und den Fenster-Koordinaten (x, y, cx, cy) in der Variable hWndInsertAfter die Konstante zur Positionierung im Fensterstapel. Außerdem bietet die Variable wFlags zahlreiche Kombinationsmöglichkeiten zur Fensterpositionierung und Manipulation. Diese würden jedoch den Umfang des Kapitels sprengen, deshalb soll an dieser Stelle auf die MSDN-Dokumentation verwiesen werden.

Ein Anwendungsbeispiel

Listing 2 enthält Funktionen, die dem Zweck dienen den Verwaltungsaufwand für die Nutzung der API-Funktionen auf ein Minimum zu reduzieren. Möchte man, wie in unserem Fall, immer nur die Gleiche Funktion nutzen, kann man benutzerdefinierte Funktionen erstellen, die uns Programmierern weniger Kenntnis um die zahlreichen Einstellungsmöglichkeiten der Parameter abverlangen. Das folgende Beispiel greift auf diese Funktionen zu und erhöht auf diese Weise die Lesbarkeit des Programmcodes. Für das Beispiel benötigen sie ein globales Modul (Listing 3) und drei weitere Formulare in die sie jeweils die Listings 4 bis 6 kopieren. Bitte achten sie genau auf die Namensgebung der Formulare (Willkommen, ErstesFormular und Zweitesformular).

Das Willkommen-Formular dient nur dem Zweck zu ermitteln wie groß der innere Bereich von Access ist, dabei ist es egal ob Access im Fenster oder in der Vollansicht mit einer 800er, 1024er oder gar 1600er Auflösung ausgeführt wird. Die Größe des verfügbaren Bereichs wird beim Öffnen des Formulars auf die beiden öffentlichen Variablen g_Height (für die Höhe) und g_Width (für die Breite) geschrieben. Wenn sie das Formular beim Programmstart automatisch öffnen lassen und durch die Timer-Funktion nach einigen Sekunden wieder schließen, wird kein Anwender diesen kleinen Trick bemerken.

Anschließend können sie die beiden Formulare [ErstesFormular] und [ZweitesFormular] öffnen , die sich beide den verfügbaren Platz sauber nebeneinander platziert teilen. Den Anteil des Formular [ErstesFormular] können sie bequem über die globale Konstante c_hPart (aus Listing 3) manipulieren. Denkbar wäre auch eine Lösung, bei der der Wert anstatt auf einer Konstante in einer Tabelle gespeichert würde, dann könnte auch ein Anwender die Starteinstellung verändern. Der besondere Clou bei dem Beispiel: verändern sie mal die Breite des linken Formulars (ErstesFormular). Das andere Fenster passt seine Größe automatisch an. Abbildung 2 zeigt eine Möglichkeit der Erweiterung dieser Lösung. Viel Spaß bei der Entwicklung neuer Einsatzgebiete, oder wissen sie gar schon eins... ;-)

Abbildung 2: Möglichkeiten mittels API-Funktionen

Listing 1: Typ- und Variablen- und API-Deklarationen

Listing 2: Funktionen, die auf API´s zugreifen

Listing 3: Variablen-Deklaration in einem globalen Modul

Listing 4: Prozedur des Formulars [Willkommen]

Listing 5: Prozedur des Formulars [ErstesFormular]

Listing 6: Prozedur des Formulars [ZweitesFormular]