|
Nervt es Sie auch, dass Sie jedes Mal das FileSystemObject aus
der MS Scripting Runtime extra instanzieren müssen, um seine
Methoden und Eigenschaften aufrufen zu können? Denn eigentlich ist
das nicht notwendig, da Sie sich durchaus mit einer einzigen
globalen Instanz zufrieden geben können. Aber auch das Anlegen
einer globalen Variablen für das FileSystemObject und das
mindestens ein einziges Mal notwendige Instanzieren ist eigentlich
immer noch zu viel und damit unnötiger Aufwand.
Warum Microsoft das FileSystemObject allerdings nicht gleich als
globales Objekt implementiert hat, so dass Sie dessen Methoden und
Eigenschaften direkt wie Visual Basic-eigene Funktionen aufrufen
könnten, ist ein wenig unverständlich. Selbst unter dem Aspekt,
dass die Scripting Runtime ursprünglich rein für Scripting-Zwecke
entstanden ist (etwa für IE- oder ASP-Scripting oder zur Verwendung
im Windows Scripting Host) und dort tatsächlich eigens instanziert
werden muss, hätte dem dennoch nichts im Wege gestanden. Denn auch
globale Objekte können jederzeit eigens instanziert werden - sogar
parallel zu ihrer globalen Verwendung.
Aber langer Rede kurzer Sinn - hiermit erhalten Sie nun die
Klasse FSO, die als Hülle um das FileSystemObjekt gelegt ist und
auf Grund der Instancing-Einstellung "6 - GlobalMultiUse"
die direkte Verwendung der Methoden und Eigenschaften erlaubt. Sie
brauchen lediglich einen Verweis auf die Komponente avbFSOWrapper in
Ihre Projekte einbinden (und natürlich trotzdem weiterhin auch den
Verweis auf die Scripting Runtime).
Nun rufen Sie die Methoden einfach direkt auf, ohne Angabe eines
Objekts - beispielsweise:
Debug.Print FileExists("c:\autoexec.bat")
In der Klasse FSO wird das FleSystemObject selbst als "As
New" deklariert
Private mFSO As New FileSystemObject
und wird somit beim ersten Zugriff automatisch instanziert. Es
"lebt" dann so lange, wie das aus dieser Klasse
instanzierte globale Objekt - auf dessen Lebensdauer haben Sie
nämlich auch keinen weiteren Einfluss, nachdem Sie einmal darauf
zugegriffen haben. Weiterhin sind lediglich alle Aufrufe
durchgeschleift - eine Arbeit, die Sie sicher genau so wie ich im
Nullkommanix erledigt hätten, die ich Ihnen aber hiermit erspare.
Ein Beispiel für das Durchschleifen:
Public Function FileExists(ByVal FileSpec As String) As Boolean
FileExists = mFSO.FileExists(FileSpec)
End Function
Und weil das Durchschleifen überall nach diesem Muster abläuft,
erspare ich Ihnen daher die Wiedergabe der übrigen Methoden in
diesem Text - Sie können ja schließlich auch den Quelltext
herunterladen und sich das in Ruhe ansehen.
Doch halt - so ganz stimmt das nicht mit dem einfachen
Durchschleifen. Eine Funktion habe ich nämlich ein wenig erweitert:
Die Funktion GetTempName kann nunmehr nicht nur einen temporären
Dateinamen zurückgeben, sondern gleich den ganzen Pfad für eine
temporäre Datei im Temp-Verzeichnis. Im neuen optionalen Parameter
können Sie die Wahl treffen, ob der Dateiname mit (Voreingestellt
ist True) oder ohne Temp-Pfad zurück gegeben wird.
Public Function GetTempName( _
Optional ByVal IncludeTempPath As Boolean = True) As String
Dim nTempFolder As Folder
If IncludeTempPath Then
With mFSO
Set nTempFolder = .GetSpecialFolder(TemporaryFolder)
GetTempName = .BuildPath(nTempFolder.Path, .GetTempName())
End With
Else
GetTempName = mFSO.GetTempName()
End If
End Function
Sicher, jetzt könnte man auch noch die Funktion GetSpecialFolder
zur Lieferung weiterer System-Ordner bewegen (siehe  "Standard-Ordner
finden"). Oder das Löschen von Ordnern und Dateien
in den Papierkorb ermöglichen (siehe "Dateien
löschen - Explorer-like" und "Die
Windows-Müllabfuhr"), oder das Kopieren ganzer
Ordner-Strukturen (siehe "Ordner-Strukturen
kopieren") und dergleichen mehr. Aber diese
Erweiterungen einzubauen überlasse ich vorläufig Ihnen - das
Rüstzeug finden Sie ja bereits in den angegebenen Artikeln...
|