infobase: EDV - MS-Access

Fenster

FENSTERGRÖßE:

Das leidige Spiel mit Vollbild- und Fenstergröße kann wirksam unterbunden werden, wenn das Fenster, das als 'kleines' auf der Oberfläche eines grösseren erscheinen soll, als 'Pop-up'-Fenster definiert wurde. So behält es seinen Größenstatus bei, auch wenn der Größenstatus des zugrundeliegenden Fensters zwischen Symbol, wiederherstellen und Vollbild gewechselt wird. Das Schöne daran ist obendrein, daß zwischen allen geöffneten Pop-up-Fenstern gewechselt werden kann. Diese Pop-up's überlagern sich jeweils gegenseitig, bleiben aber alle auf der Oberfläche des 'Mutter'-Fensters.

Ebenfalls leidig ist das Thema mit Datenblättern, die bitte schön die gesamte Bildschirm-Fläche ausnutzen sollen. Bisher wurde das mit ewigen Größenänderungen im Entwurfsmodus erreicht. Alternativ dazu geht das auch mit ' DoCmd MoveSize 0, 0, 9600, 6350 ', das geschickterweise in Form_Open oder Form_Current eingesetzt wird. In Form_Current ist es dann sogar möglich, das Formular abhängig vom Darstellungs-Modus in verschiedenen Größen zu zeigen. Fast schon omnipotent wird es dann mit siehe CenterForm.

Schönheitsfehler: Als Datenblatt geöffnet erscheint ein Formular IMMER mit den verschiebbaren Windows-Rändern; wird von hier aus in die Formularansicht gewechselt, kann zwar ein neue Formulargröße eingestellt werden, aber die Ränder sind dann nicht mehr wegzukriegen !

Aber auch hier gibt es glücklicherweise zu endlosem Code-Geficke eine wohl akzeptable Alternative:

Wird ein Formular mit den unerwünschten Rändern zum Vollbild vergrößert, verschwinden die Ränder, der komplette Bildschirmbereich unterhalb der Menüleiste, respektive einer am oberen Rand eingeblendeten Symbolleiste, steht dem Formular zur Verfügung, die manchmal praktischen Schaltflächen für Dokument-Systemmenü und Wiederherstellen werden dezent in die Menüleiste integriert und obendrein erscheint der Formularname zusätzlich zum Applikationsnamen in der Anwendungs-Systemleiste. All das wird von Windows bereitgestellt, kommt ohne Code aus und tut auch noch ! Wenn diese Eigenschaften für ein Formular also generell gefragt sein sollten, empfiehlt sich ein DoCmd Maximize in Form_Open und DoCmd Restore in Form_Close oder bei Bedarf in Activate/Deactivate. Das Restore kann auch noch von einem globalen Flag abhängig gemacht werden, das anzeigen kann, oben ein generelles Maximize erwünscht ist oder nicht. Die Steuerung über die Ereignisse Activate/Deactivate würde sogar diesen globalen Flag überflüssig machen, weil dann jedes Formular bei Fokus-Erhalt/Abgabe selbst die entsprechenden Einstellungen vornehmen könnte (und so ist's wohl auch am einfachsten).

Für den Wunsch, den Inhalt eines Text-/Memo-Feldes ähnlich wie mit <F2> in einer Art Vollbild-Modus darstellen zu lassen, wurde ein allgemeines Formular entwickelt. Es kann ohne Parameter geöffnet werden, zieht sich selbst die nötigen Daten rein und übergibt diese bei erfolgter Änderung im Vollbild-Modus auch wieder an das Steuerelement zurück, von dem aus der Aufruf erfolgte. Zu Bewundern in WISSEN.MDB.

Es ist sogar möglich, ein Formular anzuzeigen, daß den GESAMTEN Bildschirm ausfüllt.
Dies geht allerdings nur mit einem Pop-Up-Formular ( Maße bei 640 * 480: 16,998 cm Formularbreite und 12,82 cm Detailbereich-Höhe ), das dann die Access-Umgebung nicht nur optisch, sondern auch funktional aus- bzw. überblendet. Allerdings müssen dann sämtliche von hier aus geöffneten Formulare als Pop-Up-, bzw. wenn diese kleiner sein sollten, als Pop-Up und gebunden definiert werden.

Besonders schick ist es, wenn sich die Größe eines Fensters automatisch an gewisse Gegebenheiten anpasst. Hier trat mehrmals das Problem auf, daß eine Wertezuweisung a'la Section(0).Height = x manchmal nicht klappen wollte. Hierbei handelt es sich ausnahmsweise einmal nicht um einen Fehler. Das passiert immer dann, wenn versucht wird, die Höhe z.B. des Detailbereiches zu verkleinern und ein Steuerelement nach unten über den zugewiesenen Wert hinausragen würde. Access korrigiert diese Wertezuweisung dann auf den geringsten, zulässigen Wert (wie auch im Entwurfsmodus).

Einstellen des FENSTER-TITELs / Anwendungstitel / Caption / AppTitle:

Die bisherige 'Lösung' per API GetWindow und einem Dummy-Modal-Fenster ist Scheiße.

Besser ist das mit der APi-Funktion GetActiveWindow, die, wenn in Access nicht gerade ein Popup-Fenster geöffnet ist, den Titel des Applikations-Fenster einstellt.

Aber auch das hat, wie nicht anders zu erwarten war, Ärger gemacht. Da die DMT-Anwendung in einem einstellbarem Intervall anstehende Termine überprüft und meldet und auch den Titelleisten-Text aktualisiert, kam es vor, daß, wenn bei aktiver DMT-Anwendung gerade an einem anderen Programm gearbeitet wurde, der Titelleistentext dieses gerade aktiven Programmes geändert wurde, anstelle der der DMT-Applikation. Der Grund hierfür liegt darin, daß die API-Funktion GetActiveWindow nicht den Handle des aktiven Fensters, in dem der Code abläuft, sondern den des wahren, aktiven Fensters zurückgibt. An sich auch nicht schlecht, aber leider muß man so etwas immer selbst herausfinden.

So wird jetzt beim Starten der DMT-Anwendung der Handle des aktiven Anwendungsfensters ermittelt und an eine globale (pfui!) Variable übergeben, so daß der Timer-Code später nicht mit irgendwelchen ActiveWindow-Handles arbeiten muß, sondern mit dem der DMT-Applikation. So gesehen muß man auch noch dankbar dafür sein, daß sich diese Handles beim gefürchtetem Drehen der Windows-Zeitscheibe nicht auch noch der Reihe nach ändern.

Nötig hierfür sind folgende Elemente:

Zu deklarierende API-Funktionen:

Declare Function GetActiveWindow Lib "User" () As Integer
Declare Sub SetWindowText Lib "User" (ByVal hWnd As Integer, ByVal lpString As String)

Anweisungen:

Call SetWindowText(GetActiveWindow(), Titel)

Kann auf verschiedene Arten implementiert werden, z.B. direkte Verzweigung in eine App_Start-Funktion aus dem Makro autoexec oder auch in FormLoad eines halbwegs normalen Formulares.

APPTITLE:

Steht als sog. Eigenschaft unter Access97 zur Verfügung.
Damit aber etwas unter Zuhilfenahme der Dokumentation zustande zu bringen, kann man getrost vergessen.
Laut Doku kann dies per Code zwar gesetzt werden, aber kein Mucks zum Thema auslesen.
Nach nervigen Recherchen sieht die Sache aus wie folgt:

CurrentDb.Properties("AppTitle")

Obendrein sieht es mit dem Anwendungs-Symbol auch nicht gerade rosig aus.

Kein Wunder, daß in vielen Fällen bei Microsoft Datei-Bezüge immer mit vollständigem Pfad hinterlegt werden.
Die sind einfach zu blöd, mal eben im aktuellen Verzeichnis vorbeizuschauen.

So klappt's dann auch mit dem Anwendungs-Icon nicht so recht, wenn der Eintrag auf den Dateinamen reduziert oder bei vollständiger Angabe die Anwendung samt aller Komponenten an einer anderen Stelle geöffnet wird.

Private Sub SetIcon()

    On Error Resume Next

    Const APPICON = "formular.ico"

    CurrentDb.Properties("AppIcon") = Database_Dir() & "\" & APPICON

    Application.RefreshTitleBar

End Sub

Und aus die Maus ...