Dieser Artikel ist Teil des Magazins 'Access im Unternehmen', Ausgabe 5/2016.
Explorer und Shell ansteuern
Hin und wieder kommt es vor, dass Sie aus Access heraus den Windows Explorer öffnen und dabei gleich ein Verzeichnis Ihrer Wahl ansteuern möchten. Gründe dafür gibt es viele. Haben Sie etwa eine Textdatei exportiert, so macht es sich gut, dem Anwender anschließend gleich den passenden Ordner zu präsentieren und dort die Datei zu markieren. Über einige Zeilen VBA-Code rund um ein Shell-Objekt ist das schnell realisiert.
Explorer aufrufen
Der Explorer ist eine Anwendung, die die Verwaltung der Windows Shell oder zumindest Teile von ihr, erlaubt. Wir erwähnen diesen Zusammenhang nur, weil später noch ausführlicher auf Shell-Objekte unter VBA eingegangen wird.
Um ausführbare Dateien zu starten, können Sie die VBA-Anweisung Shell verwenden. Sie übergeben ihr als Parameter den Pfad zur ausführbaren Datei und optional noch den Fenstermodus, in dem sie gestartet werden soll:
Shell "Explorer.exe", vbNormalFocus
Diese Zeile öffnet den Windows Explorer in einem normalen Fenster. Sie können dieses jedoch auch gleich maximieren:
Shell "Explorer.exe", vbMaximizedFocus
Den Pfad zur explorer.exe müssen Sie nicht voll ausschreiben oder kennen, da sie sich im Suchpfad von Windows befindet. War's das schon? Nein, natürlich nicht! Denn erstens gibt es noch diverse Kommandozeilenoptionen für den Explorer, die zu erläutern wären, und zweitens stellen wir noch eine Alternative zur Shell-Anweisung vor.
ShellExecute
Vielleicht ist Ihnen diese Funktion schon einmal untergekommen. Es gibt zwar eine Windows-API-Funktion gleichen Namens, doch wir verwenden sie im Zusammenhang mit der Shell-Bibliothek, wo sie ebenfalls vorkommt und auch identische Funktionalität aufweist.
Dazu benötigen wir einen Verweis auf diese Bibliothek. Öffnen Sie im VBA-Editor unter Extras|Verweise den entsprechenden Dialog und aktivieren Sie den Eintrag Microsoft Shell Controls And Automation. Diese Bibliothek ist grundsätzlich unter jeder Version von Windows vorhanden und verweist auf die shell32.dll. Nun können Sie ein Shell-Objekt anlegen:
Dim oShell As Shell32.Shell
Set oShell = New Shell32.Shell
Wenn Sie im VBA-Objektkatalog oben die Bibliothek Shell32 auswählen und links zur Shell-Klasse navigieren, so finden Sie rechts deren zahlreiche Methoden, und deren Namen sagen bereits einiges über das Thema der Klasse aus.
Uns interessiert im Moment nur die Methode ShellExecute, die ähnlich arbeitet, wie die Shell-Anweisung von VBA, jedoch mit deutlich mehr Parametern ausgestattet ist, die die Funktionalität erweitern. Mit dieser Zeile öffnen Sie den Explorer, nachdem das Shell-Objekt angelegt wurde:
oShell.ShellExecute "explorer.exe", _
, , , "open", 1
Mehrere Parameter der Methode sind optional, was durch die Kommas deutlich wird. Zunächst erwartet die Funktion den Pfad der ausführbaren Datei, wobei dieser auch hier nicht vollständig angegeben werden muss.
Der zweite Parameter gibt die Kommandozeilenoptionen an, die der Anwendung mitgegeben werden sollen. Soll der Explorer das Verzeichnis c:windows anzeigen, so ist hier der richtige Ort für die Pfadangabe:
oShell.ShellExecute _
"explorer.exe", "c:windows"
Damit weicht die Syntax dieser Funktion von der Shell-Anweisung ab, bei der beide Angaben in einem String zu kombinieren wären:
Shell "explorer.exe c:windows"
Das macht die Sache etwas übersichtlicher. Der dritte optionale Parameter gibt den Ausführungspfad an. Wie bei Dateiverknüpfungen können Sie hier festlegen, welches Standardverzeichnis dem startenden Prozess zugeeignet wird. In der Regel kann dieser Parameter ignoriert werden.
Das Interessante an der ShellExecute-Funktion ist nun der vierte Parameter, der das sogenannte Aktions-Verb erwartet. Das sind Strings, die die auf den Prozess auszuführende Aktion angeben. Der Standard ist open für normales Starten der Anwendung. Lassen Sie den Parameter aus, so setzt Windows funktional automatisch open ein. Es gibt aber natürlich noch weitere Verben, auf die später noch die Sprache kommt.
Der letzte Parameter ist identisch mit dem der Shell-Anweisung und gibt den Fenstermodus an. Die 1 im Beispiel entspricht dem vbNormalFocus. Sie können hier also die gleichen Konstanten angeben, wie bei der Shell-Anweisung.
Damit Sie nicht in jeder Routine, die das Shell-Objekt benötigt, dieses per New neu anlegen müssen, greifen Sie zu einer Hilfsfunktion, wie in Listing 1. Dort ist in einem Modul die Variable m_Shell als globales Shell-Objekt deklariert.
Public m_Shell As Shell32.Shell
Public Function oShell() As Shell32.Shell
If m_Shell Is Nothing Then Set m_Shell = New Shell32.Shell
Set oShell = m_Shell
End Function
Listing 1: Funktion zum Zurückgeben des Shell-Objekts
Die Funktion oShell gibt dieses Objekt schlicht zurück, überprüft davor jedoch mit einem Test auf Nothing, ob es überhaupt gefüllt ist. Falls nicht, so wird der Variablen ein neues Shell-Objekt verabreicht. oShell können Sie nun an jeder beliebigen Stelle im VBA-Projekt verwenden, wenn Sie ein Shell-Objekt benötigen.
Kommandozeilenoptionen
Anhand der folgenden Prozeduren erläutern wir, wie sich der aufgerufene Explorer über Kommandozeilenoptionen steuern lässt (s. Listing 2).
Sub RunExplorerFolder()
oShell.ShellExecute "explorer.exe", "c:windows", , "open", 1
End Sub
Sub RunExplorerList()
oShell.ShellExecute "explorer.exe", "/e,c:", , "open", 1
End Sub
Sub RunExplorerRoot()
oShell.ShellExecute "explorer.exe", "/e,/root,c:windows", , "open", 1
End Sub
Sub RunExplorerSelectFolder()
oShell.ShellExecute "explorer.exe", _
"/select,c:windowssystem32", , "open", 1
End Sub
Sub RunExplorerSelectFile()
oShell.ShellExecute "explorer.exe", _
"/select,c:windowssystem32mscomctl.ocx", , "open", 1
End Sub
Listing 2: Verschiedene Routinen mit Optionen zum Starten des Explorers
Die erste Option lernten Sie bereits kennen. Sie öffnet den Explorer mit vorgegebenem Pfad (Prozedur RunExplorerFolder). In RunExplorerList ist dem Pfad c:windows noch ein /e, vorangestellt.
Das soll nach Aussage von Microsoft den Explorer im Modus mit Verzeichnisbaum links und Dateien rechts öffnen. Ohne dieses /e würde sich nur der Ordner allein öffnen. Diese Aussage ist für neuere Windows-Versionen nicht mehr gültig. Die geteilte Ansicht tritt in beiden Fällen ein.
Wie daraus aber zu erkennen ist, werden mehrere Optionen durch Kommas getrennt aneinander gefügt. Gibt man als weitere Option /root an, so wird der folgende Pfad als Startverzeichnis des Explorers angewählt (Prozedur RunExplorerRoot). Alle anderen Elemente sind ausgeblendet. Sie können in diesem Explorer also nicht auf darüber liegende Verzeichnisse oder Laufwerke wechseln.
Die entsprechenden Schaltflächen fehlen auch im Menüband.
Schließlich lässt sich über die Option /Select auch direkt ein Verzeichnis oder eine Datei im sich öffnenden Explorer markieren.
Dazu fügen Sie deren Pfad unmittelbar hinter die Anweisung an (Prozeduren RunExplorerSelectFile und RunExplorerSelectFolder).
Leider lässt sich diese Option nicht mit /root kombinieren.
Das bedeutet: Wenn Sie Verzeichnisse oder Dateien vormarkieren, so bleibt links leider der ganze Baum bestehen.
Der Versuch, beide Optionen dennoch zu kombinieren, führt ohne Fehlermeldung schlicht zur Anzeige des Desktops im Explorer.
Möchten Sie den Explorer mit der Auswahl Computer starten, so greifen Sie wie in Prozedur RunExplorerComputer aus Listing 3 zu einem Trick: Übergeben Sie einfach nur ein Komma als Options-String.
Sub RunExplorerComputer()
oShell.ShellExecute "explorer.exe", ",", , "open", 1
End Sub
Sub OpenFileExplorer(sFile As String)
oShell.ShellExecute "explorer.exe", "/select," & sFile, , "open", 1
End Sub
Sub RunExplorerSys()
oShell.ShellExecute "explorer.exe", _
"::{21EC2020-3AEA-1069-A2DD-08002B30309D}", , "open", 1 End Sub
Sub RunExplorerPrinters()
oShell.ShellExecute "explorer.exe", "/e,/root, " & _
"::{21ec2020-3aea-1069-a2dd-08002b30309d}" & _ "::{2227a280-3aea-1069-a2de-08002b30309d}", , "open", 1 End Sub
Listing 3: Prozeduren zum erweiterten Starten des Explorers
Die Routine OpenFileExplorer ist allgemeiner gehalten. Als Parameter übergeben Sie ihr in sFile den Pfad einer Datei oder eines Orders. Dieser wird dann im Explorer geöffnet und markiert, indem die /Select-Option mit der String-Variablen verkettet wird.
Nun finden Sie im Explorer ja nicht nur Elemente des Dateisystems, wie das noch bis Windows 98 der Fall war, sondern auch solche, wie Systemsteuerung oder Netzwerke. Diese Elemente besitzen keinen Verzeichnispfad.
Und dennoch kann man sie ansteuern: Dazu bedarf es anstelle des Pfads einer speziellen GUID, die das Element eindeutig identifiziert. Die Routine RunExplorerSys etwa öffnet die Systemsteuerung, weil diese grundsätzlich die angegebene GUID besitzt.
Die Schreibweise ist dabei immer gleich: vor die eigentliche GUID kommen zwei Doppelpunkte. Diese Shell-Objekte sind unter dem Namen SpecialFolders bekannt, wobei jene mit einer GUID eigentlich SpecialSpecialFolders heißen müssten, wie wir noch sehen werden.
Da diese Elemente wiederum im Prinzip Ordner darstellen können, ist auch der Bezug auf deren Unterelemente möglich. Die Systemsteuerung enthält etwa die Liste der Drucker.
Auf sie beziehen Sie sich, indem Sie an die GUID eine weitere, wie einen Unterordner durch den BackSlash getrennt, anfügen. So kommen Sie in RunExplorerPrinters direkt in die Verzeichnisliste der Drucker des Systems.
Sie fragen sich vielleicht, wo die GUIDs herkommen? Das ist leider nicht so einfach zu beantworten. Zwar gibt es generell gültige Shell-Elemente mit vorgegebener GUID, wie etwa bei der Systemsteuerung, doch durch installierbare Shell-Erweiterungen sieht die Sache auf jedem System anders aus. Zum Glück können Sie über die Shell32-Bibliothek diese GUIDs für ihr System selbst ermitteln...
Shell-NameSpaces
Bisher verwendeten wir nur die eine Methode ShellExecute des Shell-Objekts. Eine mächtige Funktion ist daneben NameSpace, die uns zu neuen Klassen der Bibliothek führt.
NameSpace übergibt man einen Parameter des Typs Variant. Dabei kann es sich um einen String oder eine Zahl handeln. Zurück bekommt man dann ein Objekt der Klasse Folder.
Die Methode ist also dafür gemacht, um virtuelle Ordner-Objekte anhand von Parametern zurückzugeben. Ein einfaches Beispiel:
Dim fld As Shell32.Folder
Set fld = oShell.NameSpace("c:") Hier bekommen wir ein virtuelles Objekt mit Bezug auf den physischen Ordner c:. Virtuell deshalb, weil ein Folder-Objekt nicht nur ein Element des Dateisystems darstellen kann, sondern abstrakt zum Beispiel auch die Drucker der Systemsteuerung.
Das Folder-Objekt hat verschiedene Eigenschaften, von der die Title-Eigenschaft vielleicht die wichtigste ist:
Set fld = oShell.NameSpace("c:") Debug.Print fld.Title
> "(C:) Windows 7"
Leider gibt Title die Bezeichnung des Folders zurück, nicht den Pfadnamen allein. Deshalb ist ein kleiner Umstand nötig. Die Eigenschaft Self des Folder-Objekts stellt ein neues Objekt der Klasse FolderItem dar, welche wiederum die Eigenschaft Path kennt. Den Pfad eines Folders ermittelt man demnach so:
Set fld = oShell.NameSpace("c:") Debug.Print fld.Self.Path
> "c:"
Statt des Strings zur Pfadangabe kann – Sie werden es sich denken können – auch eine SpecialFolder-GUID als Parameter übergeben werden:
Dim sGUID As String
sGUID = "::{21EC2020-3AEA-1069-A2DD-08002B30309D}" Set fld = oShell.NameSpace(sGUID)
Debug.Print fld.Title
> "Systemsteuerung"
Debug.Print fld.Self.Path
> "::{21EC2020-3AEA-1069-A2DD-08002B30309D}" Und schließlich wurde erwähnt, dass auch eine Zahl als Parameter für NameSpace dienen kann. Testen Sie das:
Set fld = oShell.NameSpace (0)
Debug.Print fld.Title
> "Desktop"
Debug.Print fld.Self.Path
> "C:UsersMinhorstDesktop"
Die 0 entspricht also dem Desktop-Ordner Ihres Windows-Kontos. Die Zahlen, die hier übergeben werden können, sind im Bereich von 0 bis 255. Es handelt sich um IDs von Windows-Spezialverzeichnissen, eben der Special Folders. Dies gibt uns die Möglichkeit, alle Spezialordner von Windows in einer Schleife zu enumerieren:
For i = 0 To 255
Set fld = oShell.NameSpace(i)
Debug.Print i, fld.Title
Debug.Print i, fld.Self.Path
Next i
Heraus kommt dabei ungefähr das:
0 Desktop C:UsersMinhorstDesktop
1 Internet ::{871C5380-42A0-1069-A2EA-08002B30309D} 2 Programme C:UsersMinhorstAppDataRoamingMicrosoftWindowsStart MenuPrograms
3 Systemsteuerung ::{21EC2020-3AEA-1069-A2DD-08002B30309D} 5 Dokumente C:UsersSaschaDocuments
...
Neben der Bezeichnung der virtuellen Ordner, die teilweise lokalisiert und teilweise Englisch ist, erhalten Sie also auch den Pfad jedes Elements, der entweder als Dateisystempfad oder als GUID daher kommt. Auf diese Weise ermitteln Sie selbst alle Pfade von Spezialordnern von Windows, und damit kehren wir zurück zum Aufruf des Explorers.
Um den Explorer mit dem Desktop zu öffnen, können Sie einfach diese Zeile aufrufen:
oShell.ShellExecute _
"explorer.exe", _
oShell.NameSpace(0). _
Self.Path
Das bedeutet, dass Sie sich um die Ermittlung des Pfads oder der GUIDs von Spezialordnern nicht weiter kümmern müssen, um diese im Explorer zu öffnen. Die Zahl zur Folder-ID reicht aus. Zu erwähnen wäre noch, dass es nicht zu allen Zahlen im Bereich von 0 bis 255 eine Spezialordnerentsprechung gibt.
Der Aufruf von Namespace mit einer solchen ungültigen Zahl führt in der Schleife zu einem Fehler. Deshalb muss ihr ein On Error Resume Next vorangestellt werden, um diese Fehler zu ignorieren.
Damit die ganze Geschichte noch anschaulicher wird, enthält die Beispieldatenbank im Modul mdlShell einige Prozeduren, mit denen die Spezialordner in Tabellen geschrieben werden können. Wegen ihres Umfangs lassen wir ihre Darstellung in Listings hier ausnahmsweise außen vor.
Rufen Sie etwa die Prozedur StoreSpecialFolders auf, so schreibt diese die gewünschten Angaben in die Tabelle tblShellFolders. Das Ergebnis sieht aus wie in Bild 1. In der Spalte SFID stehen die Nummern der Ordner, in Name deren Bezeichnung und unter Path der Pfad. Unter jedem Windows-Konto kommen hier unterschiedliche Werte heraus!
Um die Angelegenheit noch weiter aufzubohren, existieren in der Datenbank drei weitere Tabellen, die sich um die speziellen GUID-Ordner ranken. Das Datenmodell finden Sie in Bild 2.
Die Tabelle tblSpecialFolders gleicht in ihrem Aufbau der tblShellFolders, nur dass hier ausschließlich die virtuellen GUID-Ordner abgespeichert werden (s. Bild 3).
Sie füllen sie über die Prozedur NameSpacesToTable.
Da ein Ordner sowohl Elemente als auch Unterordner enthalten kann, enumeriert die Routine NamespaceFoldersToTable auch diese, um sie in der verknüpften Tabelle tblSpecialSubFolders zu speichern (s. Ausschnitt in Bild 4).
Hier sind etwa die einzelnen Elemente der Systemsteuerung zu finden, wobei es sich dabei nur teilweise um Unterordner handelt. Die Energieoptionen etwa sind kein Ordner, sondern ein Ordnerelement (FolderItem).
Hingegen handelt es sich bei der Verwaltung tatsächlich um einen virtuellen Ordner, der seinerseits Elemente wie die Ereignisanzeige oder den ODBC-Datenquellenadministrator enthält.
Damit auch diese Elemente in die Übersicht gelangen, enumeriert die Routine NamespaceFolderItems alle Elemente aller Unterordner und speichert diese in der Tabelle tblSpecialItems (s. Bild 5). Sie sehen, dass damit etwa auch alle installierten Drucker aufgeführt werden. Zu Laufwerken werden sowohl deren Ordner, wie auch etwaige Dateien aufgeführt. Bei unserem Test füllte sich die Tabelle deshalb mit über 2.000 Datensätzen.
Nachdem alle Routinen durchlaufen wurden, kann die Tabelle tblSpecialFolders als Datenblatt geöffnet werden und zeigt dabei die Detailtabellen, hierarchisch gemäß den Tabellenbeziehungen, als Unterdatenblätter an, wie Bild 6 demonstriert. Die Systemsteuerung enthält die Auflistung Verwaltung und diese selbst 16 Elemente.
Shell-Verbs
Der Aufruf des Explorers über das Shell-Objekt, statt über die Shell-Anweisung von VBA, hatte noch einen weiteren Vorteil. Das open-Verb führt zu normalem Öffnen der Anwendung. Doch hier lassen sich, je nach Anwendung, auch andere Verben einsetzen. Ein recht spezieller Fall ist das Verb runas.
Das sagt Windows, dass die Anwendung im Adminstratorkontext gestartet werden soll, nicht im Benutzerkontext. Führt man dies aus, so meldet sich Windows mit der üblichen UAC-Sicherheitsabfrage, die das Starten des Prozesses erst einmal bestätigen lässt.
Bei Bejahung hat man mit dieser Zeile ein Explorer-Fenster geöffnet, das administrative Vorgänge zulässt:
oShell.ShellExecute "explorer.exe", , , "runas", 1
Selbstverständlich könnten Sie auch hier weitere Angaben zu den Öffnungsoptionen und Pfaden machen.
Nebenbei lässt sich über dieses Verb auch eine neue Instanz von Access selbst starten, die über administrative Rechte verfügt:
oShell.ShellExecute _
SysCmd(acSysCmdAccessDir) & _
"msaccess.exe", , , "runas", 1
Diese Instanz und ihre VBA-Routinen könnten dann – einen schönen Gruß an die Hacker unter Ihnen! – etwa auch in geschützte Systemverzeichnisse schreiben.
Mit dem Aufruf des Explorers haben die folgenden Ausführungen nichts mehr zu tun, wir möchten Ihnen die Hintergründe zu Shell-Verben aber nicht vorenthalten. Listing 4 zeigt eine Prozedur, die alle möglichen Verben eines Druckers ausgibt.
Sub SFVerbs()
Dim fld As Folder
Dim itm As FolderItem
Dim vrb As FolderItemVerb
Set fld = oShell.NameSpace(4)
Set itm = fld.Items.Item(1)
For Each vrb In itm.Verbs
Debug.Print vrb.Name
Next vrb
End Sub
Listing 4: Ausgeben aller Verben eines bestimmten Druckers
Zunächst wird das Folder-Objekt fld auf den virtuellen Drucker-Ordner von Windows gesetzt, der durch die Special Folders-ID 4 bestimmt ist. Dann nimmt die Prozedur den ersten Drucker, das erste Element in Gestalt des FolderItems 1, und enumeriert in einer For-Each-Schleife alle Verben (Objektvariable vrb) dieses Shell-Objekts, um sie im VBA-Direktfenster auszugeben. Jedes FolderItem-Objekt hat diese Auflistungseigenschaft Verbs.
Als Ergebnis erhalten Sie etwa diese Liste:
Ö&ffnen
Als &Standarddrucker festlegen
&Druckeinstellungen...
Drucker &anhalten
Frei&geben...
Drucker &offline verwenden
A&ktualisieren
Ve&rknüpfung erstellen
&Löschen
&Umbenennen
E&igenschaften
Sie könnten auch etwa das Folder-Objekt auf einen Dateipfad setzen und bekämen dann eine ganz andere Liste zu Gesicht.
Bedauerlicherweise handelt es sich hier um lokalisierte Verben, die sich nicht direkt als Verb für ShellExecute einsetzen lassen. Es gibt auch keine Übersetzungsfunktion. Eine gültige Liste der Verben für ShellExecute ist jedenfalls diese:
open - Öffnen
edit - Bearbeiten
copy - Kopieren
cut - Ausschneiden
print - Ausdrucken
runas - Als Administrator starten
properties - Eigenschaften anzeigen
find - Suchen-Dialog anzeigen
Diese Verben funktionieren nur bei bestimmten Shell-Objekten. Für die explorer.exe etwa machen das Ausschneiden oder Drucken keinen Sinn.
Für DVD-Laufwerksobjekte hingegen gäbe es auch noch das Verb eject, welches die Laufwerksschublade öffnet.
Unterschlagen haben wir bisher auch, dass sich ShellExecute im Gegensatz zu VBA-Shell nicht nur auf ausführbare Dateien beschränkt, sondern mit allen Dateitypen funktioniert.
Übergeben Sie als Argument etwa eine Textdatei, so öffnet sich diese mit der verknüpften Anwendung – vermutlich Notepad. Listing 5 zeigt, wie auf ein FolderItem zur Datei sample.txt zwei unterschiedliche Verben angewandt werden.
Sub InvokeAVerb()
Dim fld As Folder
Dim itm As FolderItem
Dim vrb As FolderItemVerb
Set fld = oShell.NameSpace(CurrentProject.Path)
Set itm = fld.Items.Item("sample.txt") For Each vrb In itm.Verbs
' Debug.Print vrb.Name
Next vrb
itm.InvokeVerb "edit"
itm.InvokeVerb "properties"
End Sub
Listing 5: Verben ausführen
Seine Methode InvokeVerb lässt die Shell-Aktion ausführen, wobei hier einmal edit für Bearbeiten und einmal properties zur Anzeige des Eigenschaftendialogs der Datei eingesetzt sind.
Zusammenfassung und Ausblick
Wann immer Sie von einer Access-Anwendung aus auf Anweisung des Benutzers Dateien erstellen lassen, die der Benutzer weiterverarbeiten soll, macht es sich sehr gut, wenn der Benutzer – zumindest optional – gleich den Windows-Explorer mit dem Ordner angezeigt bekommt, in dem die Datei gelandet ist.
Anwendungsfälle hierfür gibt es genügend. Wenn der Benutzer beispielsweise einen vorgefertigten XML-Export auf Basis der aktuellen Daten exportiert, um diesen gleich im Anschluss in ein anderes Programm einzupflegen, das sich nicht direkt von Access aus füttern lässt, wird er sich freuen, wenn er das Export-Verzeichnis nicht extra noch öffnen muss. Stattdessen bekommt er direkt den Windows Explorer mit dem entsprechenden Verzeichnis und der markierten Datei präsentiert.