Switchboards oder Menü- und Symbolleisten und nun auch Ribbons sind die gebräuchlichen Mittel zur Navigation in Datenbankanwendungen. Switchboards sind nicht sonderlich übersichtlich, weil sie immer wieder von Formularen oder Berichten überlagert werden. Menüleisten wiederum haben einen kleinen Nachteil: Sie dehnen sich horizontal aus und nehmen damit in der Vertikalen Raum ein, der ergonomischer etwa für die Anzeige einer zusätzlichen Reihe Datensätze verwendet werden könnte. Auf Webseiten hingegen dürfte ein seitliches Menü die häufigste Navigationsmethode sein. Ist das, was dort möglich ist, nicht auch unter Access machbar
Menü zur Seite
Es ist etwas paradox: Der für die eigentlichen Inhalte zur Verfügung stehende Raum wird immer kleiner. Nehmen wir etwa ein aktuelles Notebook mit der üblichen Bildschirmauflösung von 1280 x 800 Pixel und ein installiertes Office 2007.
Das Ribbon nimmt, wenn die Schnellstartleiste unten angedockt ist, bereits 170 Pixel Höhe ein. Ist für Formulare und Tabellen die Registerkartenansicht aktiviert – plus 20 Pixel für die Reiter – und soll auch die Statusleiste (22 Pixel) angezeigt werden, dann bleibt für die Datenblattanzeige abzüglich ihrer Navigationsleiste (22 Pixel) und der meist unten angedockten Taskleiste (26 Pixel) gerade noch eine Höhe von 540 Pixel vertikal übrig. Das steht im Gegensatz zur Tatsache, dass sich Tabellen und Listen eher vertikal ausdehnen als horizontal. Man hat also vergleichsweise wenige Datensätze im Blick.
Auch, wenn eine Menüleiste an sich eine geringe Höhe aufweist, ist zu fragen, warum man ein Menü nicht genau so gut seitlich anbringen könnte, wie das in anderen Anwendungen, etwa in Outlook oder im Internet, ja auch praktiziert wird.
Für diesen Zweck existieren tatsächlich spezielle ActiveX-Steuerelemente namens “Outlook-Bars”, die aber den Nachteil haben, dass sie als Container ein Formular benötigen, das dauernd im Hintergrund geöffnet sein muss.
Es lässt sich jedoch auch mit Access-Bordmitteln durchaus ein brauchbares Seitenmenü realisieren – denn Menü- und Symbolleisten lassen sich schließlich auch seitlich und vertikal andocken.
Für diesen Beitrag lassen wir Access 2007 außen vor und beschränken uns auf die früheren Versio-nen, die noch andockbare Menüleisten unterstützen. Eine analoge Lösung für Access 2007 wäre das Erstellen eines benutzerdefinierten Taskpanes (siehe Beitrag Custom Task Panes mit VB6, Shortlink 528).
Vertikale Menüleisten
Wer eine der Standardmenü- oder Symbolleisten seitlich im Access-Rahmenfenster andockt, ist ernüchtert. Denn auch die Schaltflächen und ihre Beschriftungen erscheinen dann vertikal ausgerichtet und wer nicht dauernd den Kopf verrenken möchte, dem bringt das wenig. Über den “Anpassen”-Dialog der Menüleisten kann man die Schaltflächen jedenfalls nicht dazu bewegen, sich anders auszurichten. Das ist unverständlich, denn Microsoft hat durchaus eine Einstellung vorgesehen, mit der die 90°-Drehung vollzogen werden kann. Nur lässt sich die ausschließlich per VBA vornehmen.
Inspiziert man die Möglichkeiten eines CommandbarButton-Objekts, also einer Menüschaltfläche, im Objektkatalog (Microsoft Office-Library), dann trifft man auf die Eigenschaft Style.
Diese kann den Wert einer der vordefinierten msoButtonStyle-Konstanten annehmen. Setzt man Style auf msoButtonWrapCaption, dann dreht sich die Schaltfläche und wird zu einem brauchbaren Steuerelement. Testen Sie selbst:
Ziehen Sie die Datenbank-Symbolleiste von Access mit der Maus oben ab und docken Sie sie links am Rand von Access wieder an. Setzen Sie danach diese Anweisung im VBA-Direktfenster ab:
Commandbars("Database").Controls(1).Style = msoButtonWrapCaption
Der Menüeintrag für Neu… hat sich damit gedreht. Interessant ist nun, dass sich die Breite der Symbolleiste automatisch der Breite einer Beschriftung anpasst:
Commandbars("Database").Controls(1).Caption = _
"Neue_Datenbank_anlegen..."
Setzte man statt der Unterstriche Leerzeichen in die Beschriftung, dann würde der Text umbro-chen. Access legt grundsätzlich für jedes Leerzeichen in Schaltflächenbeschriftungen einen Umbruch an.
Das geht so weit, dass eine Schaltfläche, deren Beschriftung nur aus drei Leerzeichen besteht, dreimal so hoch wird wie üblich. Man kann das vermeiden, indem man statt der “korrekten” Leerzeichen mit dem Ordinalwert 32 gesperrte Leerzeichen mit dem Wert 160 verwendet:
Set oCmd = Commandbars("Database").Controls(1). _
Caption = Replace("Neue Datenbank anlegen", _
" ", Chr(160))
Wenn die Schaltfläche sich nun durch die längere Beschriftung verbreitert, dann müsste sich folge-richtig auch ihre Eigenschaft Width verändert haben – denkt man. Tatsächlich beträgt sie nun 136 statt 37 Pixel:
Debug.Print oCmd.Width
Der Versuch, die Schaltfläche über diese Eigenschaft weiter zu verbreitern, führt indessen zu einem irritierenden Ergebnis:
oCmd.Width = 150
Sie wird nun nicht breiter, sondern höher! Verändert man hingegen die Höhe mit
oCmd.Height = 150
dann wird sie nicht höher, sondern breiter. Es scheint, dass sich durch die Drehung der Schaltfläche über die Style-Eigenschaft die Koordinaten vertauscht haben.
Merkwürdigerweise gibt die Abfrage von Width und Height nun aber durchaus die korrekten Ausmaße wieder. Lesen und Setzen der Eigenschaften Width und Height unterscheiden sich demnach.
Was man sich hierbei lediglich merken sollte: Die Breite einer Schaltfläche und damit der vertikalen Menüleiste insgesamt lässt sich mit der Eigenschaft Height verändern. Und das ist auch schon der einzige Weg, um die Breite der Leiste zu setzen, denn die Anweisung
Commandbars("Database").Width = 150
führt zu einem Automatisierungsfehler – die Menüleiste bleibt hinsichtlich der Breite hartnäckig dynamisch an deren Elemente angepasst.
Wer zusätzlich zum Text der Schaltflächen auch noch Symbole anzeigen will, der kann die Style-Eigenschaft auf msoButtonIconAndWrapCaption stellen, wird dann aber möglicherweise enttäuscht sein, denn die Bildchen zeigen sich nun grundsätzlich zentriert über der Beschriftung, was nicht gut aussieht und außerdem die Schaltfläche doppelt so hoch macht. Es gibt keine Style-Konstante, die dem abhelfen könnte. Wir beschränken uns daher im Folgenden auf reine Textmenüs.
Bevor es an die Erstellung der kompletten Leiste geht, soll noch die Frage geklärt werden, ob auch Untermenüsteuerelemente eingesetzt werden können.
Das ist jedoch schnell beantwortet: Nein. Ein Untermenü entspricht dem Objekt CommandbarPopup, welches keine Style-Eigenschaft kennt.
Deshalb bliebe es immer vertikal ausgerichtet und passt nicht mehr ins Bild. Wie man dennoch verschachtelte Menüs erzeugen kann, dazu gibt es später Lösungsangebote.
Nebenbei: Sollten Sie mit den bisherigen Code-Anweisungen Ihre Datenbank-Symbolleiste optisch verhunzt haben, dann ziehen Sie sie wieder in die frühere horizontale Position, gehen auf Anpassen und aktivieren für die fraglichen Steuerelemente den Kontextmenüeintrag Schaltflächensymbol zurücksetzen. Das sollte auch Breite und Höhe der Buttons wieder in die alte Form bringen.
Nordwind extended
Damit Sie sich schon mal ein Bild davon machen können, wie die Menüleiste letztendlich aussehen soll, finden Sie einen Screenshot in Bild 1. Es handelt sich um die originale Nordwind-Datenbank, welche um die Sidebar-Navigation erweitert wurde und auf der Heft-CD unter dem Namen de-mo_navibar.mdb zu finden ist. Nordwind-Formulare und -Berichte lassen sich komplett über die neue vertikale Menüleiste aufrufen.
Bild 1: Die Nordwind-Datenbank mit neuer Benutzerführung in Gestalt einer vertikalen Menüleiste
Schauen wir uns die grundlegenden Features der Menüführung an.
Zunächst sind alle Standardmenü- und Symbolleisten ausgeblendet. Dadurch bleibt zusätzlicher vertikaler Platz für maximierte Formulare und Berichte. Ganz unten jedoch gibt es eine zusätzliche Leiste, die lediglich eine Schaltfläche Schließen beherbergt.
Diese wird aktiv, sobald ein Formular oder Bericht geöffnet ist. Die Schließen-Schaltfläche macht dann auch das, was sie verheißt, und schließt jegliches offene Objekt. Damit spart man sich entsprechende Schaltflächen in den einzelnen Formularen ein.
Über den Anpassen-Dialog finden Sie drei neue Leisten in der Datenbank, wovon eine, die NavibarSub, ausgeblendet oder noch gar nicht vorhanden ist (siehe Bild 2). Ihre Bedeutung wird später erläutert.
Abb.3: Einstellungen der benutzerdefinierten Leisten
Alle Leisten sind so eingestellt, dass sie sich vom Benutzer nicht ändern lassen (siehe Bild 3).
Bild 4: Die fertige Hauptmenüleiste der Anwendung
Im Auslieferungszustand enthält die Hauptmenüleiste noch keine Steuerelemente, denn diese werden als temporäre Objekte erst nach dem Start der Anwendung über das AutoExec-Makro dynamisch angelegt, und zwar gesteuert über die Tabelle tbl_Navibar.
Die Hauptmenüleiste (siehe Bild 4) zeigt einige bunte Schaltflächen, die den Eindruck aufkommen lassen, dass hier mit unterschiedlichen Farbzuweisungen gearbeitet wurde. Tatsächlich gibt es in dieser Hinsicht aber keinerlei Anpassungsmöglichkeiten für Menüs.
Bild 5:
Die Farben, die übrigens nur unter Office 2003 so aussehen und in Office 2000 in reinem Grau erstrahlen, kommen durch einen Trick zustande: Die Enabled-Eigenschaft der CommandbarButtons wirkt sich auf die Schriftfarbe aus und wird bei False ausgegraut dargestellt.
Wird der Status der Schaltfläche über die Eigenschaft State jedoch zusätzlich auf msoButtonDown gestellt, also gedrückt, dann wechselt die Oberflächenfarbe in Orange.
Über diese Farben haben Sie die Möglichkeit, quasi Labels als Überschriften zu logischen Anweisungsblöcken anzulegen – die deaktivierten Schaltflächen können ja nicht angeklickt werden.
Um die einzelnen Schaltflächen besser von einander abzusetzen, haben sie außerdem alle die Eigenschaft BeginGroup = True – “Gruppierung beginnen” -, was die Unterteilungslinien zwischen Steuerelementen anzeigt.
Handicap: Wenn Sie eine solche Menüleiste anlegen, dann hat sie leider für unseren Zweck einen Makel, weil ab Office XP an ihrem unteren Rand ein Pfeil sichtbar ist, der auf Klick die Möglichkeit zum Schaltflächen hinzufügen oder entfernen anbietet (siehe Bild 5).
Bild 2: Die drei benutzerdefinierten Menüleisten für die Navigation in Nordwind Extended
Diese Möglichkeit, unsere Navigationsleiste zu verunstalten, soll dem Benutzer jedoch vorenthalten werden. Doch leider gibt es keine Methode über das Objektmodell von Office auf das Pfeilchen einzuwirken. In die Demodatenbank ist deshalb eine Gewaltlösung eingebaut, die den unteren Rand der Leiste per API unsichtbar macht. Dazu später mehr.
In umfangreichen Datenbanken wird es die Höhe des Access-Fensters nicht hergeben, dass ausrei-chend Menüeinträge angezeigt werden können. Da Untermenüs in vertikalen Leisten, wie erwähnt, wegen fehlender Drehbarkeit nicht wirklich möglich sind, kommt für Untermenüs ein weiterer Trick zum Einsatz.
Bei Klick auf eine Menüschaltfläche mit Pfeil, wie etwa in Bild 6 die für Umsätze >, öffnet sich rechts eine zusätzliche Menüleiste, die die Schaltflächen für die Untermenüpunkte enthält. Wird dort eine Schaltfläche angeklickt, dann schließt sich die Leiste wieder.
Bild 6: Das Pseudo-Untermenü eines Menüeintrags
Zu beurteilen, ob diese Lösung das Gelbe vom Ei ist, überlasse ich Ihnen. Denn das Ganze hat einen unschönen Nebeneffekt: Ein maximiert geöffnetes Formular wird beim Einblenden der zusätzlichen Leiste horizontal zusammengequetscht.
Deshalb gibt es mit der zweiten Beispieldatenbank zu diesem Beitrag, der Datei demo_navibar_ol.mdb, eine alternative Lösung, die ohne zusätzliche Leiste auskommt.
Dort werden die Schaltflächen der Hauptmenüleiste dynamisch nach oben oder unten verschoben und es ist immer nur eine Kategorie sichtbar – der “Outlook-Effekt” eben.
Tabellensteuerung
Beim Start der Datenbank Nordwind Extended führt das AutoExec-Makro die Funktion CreateNaviGUI aus, die sich übrigens mit allen weiteren Prozeduren zur Steuerung der Leisten im Modul mdlNavi befindet.
Sie können dieses Modul neben den benötigten Tabellen tbl_NaviBar und tlb_NavibarSub auch in Ihre Datenbanken importieren, wenn Sie eigene Sidebars realisieren möchten.
Die Prozedur CreateNaviGUI tut nur wenig: Sie blendet die Standardmenüleisten von Access aus, die untere benutzerdefinierte (NavibarClose) ein und ruft schließlich die Prozedur FillNaviBar zum Anlegen der Schaltflächen in der Hauptmenüleiste Navibar auf:
Function CreateNaviGUI()
On Error Resume Next
CommandBars("Menu bar").Enabled = False
CommandBars("Database").Visible = False
CommandBars("NavibarClose").Visible = True
FillNaviBar
End Function
FillNaviBar stürzt sich nun über ein Recordset auf die Tabelle tbl_Navi (siehe Bild 7) und erzeugt aus ihren Datensätzen Schaltflächen mit den gewünschten Eigenschaften.
Bild 7: Tabelle tbl_Navibar zur Steuerung der Menüleistenschaltflächen
Die Felder der Tabelle haben folgende Bedeutung:
- Ein Datensatz steht für jeweils eine Menüschaltfläche.
- ID ist der Primärschlüssel (Autowert) der Tabelle und wirkt sich selbst nicht auf die Schaltflä-chenerzeugung aus.
- Position ist ein Long-Wert, der die Reihenfolge bestimmt, in der die Schaltflächen von oben nach unten angelegt werden.
- Caption ist die Beschriftung einer Schaltfläche.
- IsLabel gibt an, ob die Schaltfläche als Gruppierungs-Label dienen soll und unter Access 2003 dann orange erscheint. In der Routine führt dieses Feld zum Setzen der State-Eigenschaft auf msoButtonDown.
- Enabled steuert, ob die Schaltfläche aktiviert sein soll oder nicht.
- Height steuert die Höhe der Schaltfläche. Der erlaubte Wertebereich erstreckt sich von 1 bis 3. Man kann hier etwa für die orangefarbenen Gruppierungsschaltflächen einen höheren Wert als 1 angeben, um sie deutlicher hervorzuheben.
- Action ist ein String, der bei Klick auf eine Schaltfläche als Parameter an die benutzerdefinierte Funktion fuCmbAction geleitet wird, wo er über ein Select Case-Statement ausgewertet und in die gewünschten nachfolgenden Funktionsaufrufe umgesetzt wird.
- Tooltipp ist ein String, der zusätzliche Infos zur Bedeutung einer Menüschaltfläche ausgeben soll, wenn der Mauszeiger sich über ihr befindet.
An den Pluszeichen vor ID erkennen Sie, dass an die Tabelle ein Unterdatenblatt angeflanscht ist. Hierbei handelt es sich um die Tabelle tbl_NavibarSub, die genau den gleichen Aufbau hat und die Einträge für mögliche Untermenüs enthält.
Ein Klick auf das Pluszeichen zum Datensatz mit der ID 7 (Umsätze) etwa offenbart, dass zu diesem ein Untermenü mit Detaildatensätzen existiert.
Die Untermenüleiste wird in FillNavibar aber noch nicht erzeugt. Das geschieht erst zur Laufzeit über die Prozedur ShowSubNavi, wenn ein entsprechender Menüeintrag angeklickt wird.
Der Kern der Routine FillNavibar durchläuft die auf der Tabelle tbl_Navibar basierende Datensatzgruppe rstNavi (s. Listing 1). Bei CtlB handelt es sich dabei um eine als CommandbarButton deklarierte Variable, bei cmb um ein Commandbar-Objekt, das auf die Menüleiste Navibar verweist.
Listing 1: Tabellengesteuertes Anlegen der CommandbarButtons der Menüleiste in einer Schleife
Do While Not rstNavi.EOF
Set CtlB = cmb.Controls.Add(msoControlButton, , , , True)
With CtlB
.Height = 160
.Style = msoButtonWrapCaption
.DescriptionText = Nz(rstNavi!Tooltip)
.TooltipText = Nz(rstNavi!Tooltip)
strCaption = Nz(rstNavi!Caption, " ")
ReplaceSpaces strCaption
If rstNavi!IsLabel Then
strCaption = fuTitleCaption(strCaption)
.BeginGroup = False
.state = msoButtonDown
.Enabled = False
bLastGrouped = True
Else
strCaption = Trim(strCaption)
.BeginGroup = Not bLastGrouped And (Len(strCaption) > 0)
bLastGrouped = False
.Enabled = rstNavi!Enabled And (Len(strCaption) > 0)
If Not IsNull(rstNavi!Action) Then
.OnAction = _
"=fuCmbAction(" & Chr$(34) & rstNavi!Action & Chr$(34) & ")"
End If
End If
.Caption = strCaption
.Width = Choose(rstNavi!Height, 16, 24, 36)
End With
rstNavi.MoveNext
Loop
Zunächst wird für jeden Datensatz eine Schaltfläche über die Controls.Add-Methode des Commandbars erzeugt, wobei der optionale Parameter Temporary auf True gesetzt wird.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo