The SOSCQ Page (Excel) - Bekannte Probleme in VBA

Wenn Sie als VBA-Programmierer nicht nur kleine Makros sondern grössere Anwendungen schreiben, werden Sie ziemlich schnell in den Genuss der Programmierung von Datei- und Verzeichnis-Zugriffen kommen. Natürlich ist das Öffnen und Speichern anhand den Excel-Methoden Open und Save/SaveAs nicht sonderlich schwierig. Auch die Suche nach bzw. die Existenzprüfung von Dateien kann mit dem FileSystemObject-Objekt, dem FileSearch-Objekt, der Dir-Funktion oder auch einer API-Funktion sehr einfach realisiert werden. Leider existieren in VBA/Excel-VBA ein paar Fehler und Unschönheiten, die einem das Leben so richtig schwer machen können.

Damit Sie nicht unnötig Zeit und Aufwand in die Entwicklung von Programmcode investieren, der am Ende womöglich gar nicht funktioniert, stelle ich Ihnen auf dieser Seite die wichtigsten Probleme und deren Lösungen vor.

Eine grosse Sammlung von VBA-Codebeispielen finden Sie hier:

	Weitere Informationen
	VBA-Codebeispiele

[01] Seltsames Verhalten des Auswahl-Listenfeldes "Dateityp" im Öffnen-Dialog

Das Auswahl-Listenfeld "Dateityp" des Datei öffnen-Dialoges verhält sich in bestimmten Situationen nicht so, wie es der Benutzer eigentlich erwartet. Die folgende Abbildung zeigt das Dialogfenster, in dessen Dateiliste auch Dateien aufgeführt sind, die nicht mit dem gewählten Suchkriterium übereinstimmen.

Dialog "Datei öffnen"
Abbildung: Datei öffnen-Dialog von Microsoft Excel

Wie in der obigen Abbildung zu sehen ist, wurde im Feld "Dateiname" das Suchkriterium "*.xla" eingetragen und der Dateityp auf "Microsoft Excel-Dateien (*.xl*; *.xls; *.xlt; *.xla)" eingestellt (entspricht der Vorgabe-Einstellung). Mit diesem Filter werden drei übereinstimmende Dateien gefunden, wie in der Dateiliste zu erkennen ist (siehe Abbildung). Es handelt sich dabei um zwei Add-Ins mit der Dateiendung .xla und um eine Arbeitmappe mit der Dateiendung .xls. Beachten Sie, dass die Arbeitsmappe (xls-Datei) nicht aufgeführt werden dürfte, da für "Dateiname" das Suchkriterium "*.xla" eingegeben wurde und eine xls-Datei zweifellos nicht die Endung "*.xla" besitzt.

[02] Verwendung von "Dir" und "Name" führt zu Fehler 75 "Fehler beim Zugriff auf Pfad/Datei"

Die Dir-Funktion von VBA besitzt aufgrund einer nicht ganz sachgemässen Implementierung die Eigenheit, die in bestimmten Situationen zu einem schwer nachvollziehbaren Verhalten führt. Das Problem existiert allerdings nur unter Windows NT (alle NT-Versionen). Wenn bei der Dir-Funktion eine existierende Datei als Parameter angegeben wird, so wird diese Datei von Dir fälschlicherweise blockiert. Dieses Verhalten ist dann problematisch, wenn nach der Codezeile mit der Dir-Funktion beispielsweise der Ordner, in welchem sich die bei Dir als Paramenter angegebene Datei befindet, anhand der Name-Anweisung umbenannt werden soll. Die Auswirkung des Problems ist der VBA-Laufzeitfehler 75.

Abbildung: Laufzeitfehler 75 "Fehler beim Zugriff auf Pfad/Datei"

Problem
In diesem Beispiel wird überprüft, ob sich die Datei "MeineMappe.xls" im Ordner "C:\NeueDaten" befindet. Wenn dies der Fall ist, soll der Ordner in "C:\AlteDaten" umbenannt werden.

Beispiel (Problem)
Sub VerzeichnisUmbenennen()
Dim strFile As String
strFile = Dir("C:\NeueDaten\MeineMappe.xls")
If strFile <> "" Then
Name "C:\NeueDaten" As "C:\AlteDaten"
End If
End Sub

Wenn Sie die Prozedur starten, werden Sie bei Ausführung der Codezeile "Name "C:\NeueDaten" As "C:\AlteDaten"" den Laufzeitfehler 75 "Fehler beim Zugriff auf Pfad/Datei" erhalten.

Lösung
Dieses Beispiel funktioniert auch unter Windows NT und enthält verglichen mit dem obigen Beispiel (Problem) lediglich eine zusätzliche Codeziele. Bevor der Ordner umgenannt wird, erfolgt ein nicht näher spezifizierter Zugriff mittels Dir auf die Dateien eines anderen Ordners (im Beispiel "C:\*.*"). Dadurch wird quasi die Referenz auf die Datei "MeineMappe.xls" aufgehoben.

Beispiel (Lösung)
Sub VerzeichnisUmbenennen()
Dim strFile As String
strFile = Dir("C:\NeueDaten\MeineMappe.xls")
If strFile <> "" then
strFile = Dir("C:\*.*")
Name "C:\NeueDaten" As "C:\AlteDaten"
End If
End Sub

Hinweis
Das oben beschriebene Verhalten tritt nur unter Windows NT auf. Das ist zwar einerseits gewissermassen 'erfreulich', erschwert andererseits jedoch die Fehlersuche, da ein Makro mit Dir und Name auf Arbeitsstationen mit beispielsweise Windows 95 problemlos ausgeführt werden kann, auf anderen Arbeitsstationen (mit Windows NT) aber zum Laufzeitfehler 75 "Fehler beim Zugriff auf Pfad/Datei" führt.

Anmerkung des Autors
Dieses Problem konnte ich sowohl in Microsoft Office 97 als auch in Microsoft Office 2000 reproduzieren.

[03] Dateimodifikation innerhalb einer Schleife mit "Dir" führt zu Endlosschleife

Häufig wird die Dir-Funktion innerhalb einer Programmschleife, beispielsweise einer Do-Loop-Schleife, verwendet, um alle übereinstimmenden Dateien zu einem bestimmten Suchmuster (z.B. alle xls-Dateien) zu durchlaufen. In einer bestimmten Situation jedoch führt dieses Vorgehen zu einer Endlosschleife.

Das Ermitteln aller xls-Dateien eines Ordners ist einfach zu programmieren, wie das folgende kleine VBA-Beispiel zeigt:

Beispiel
Sub ZeigeDateien()
Dim strDatei As String
strDatei = Dir("C:\ExcelDaten\*.xls")
Do While strDatei <> ""
MsgBox strDatei
strDatei = Dir()
Loop
End Sub

Problem
Es existiert jedoch eine besondere Einschränkung, die dazu führt, dass die Schleife trotz korrekter Angabe der Bedingung zur Beendigung der Schleife (While-Ausdruck) endlos ausgeführt und nie mehr verlassen wird. Diese Endlosschleife tritt dann auf, wenn innerhalb der Schleife eine mit der Dir-Funktion ermittelte Datei modifiziert wird.

Beispiel (Problem)
Sub ZeigeDateienAlt()
Dim strDatei As String
strDatei = Dir("C:\ExcelDaten\*.xls")
Do While strDatei <> ""
    MsgBox strDatei
    SetAttr strDatei, vbNormal
    strDatei = Dir()
Loop
End Sub

Im obigen VBA-Beispiel werden die Dateiattribute der von der Dir-Funktion zurückgegebenen Datei auf "Normal" gesetzt. Gewöhnlich ermittelt die Codezeile "strDatei = Dir()" die jeweils nächste Datei, die mit dem angegebenen Suchmuster (im Beispiel "C:\ExcelDaten\*.xls") übereinstimmt. Durch die Modifikation der Dateiattribute wird aber die intern geführte Liste der übereinstimmenden Dateien zurückgesetzt. Als Folge liefert die Zeile "strDatei = Dir()" nicht die nächste Datei sondern wieder die erste Datei. Deren Attribute werden in der Schleife geändert und beim nächsten Dir-Aufruf wieder die erste Datei zurückgegeben, was in einer Endlosschleife resultiert.

Lösung
Damit der VBA-Code funktioniert, darf die Dateiänderung nicht in der Schleife mit der Dir-Funktion durchgeführt werden. Als Lösung empfehle ich daher zwei Programmschleifen: Die erste Schleife (eine Do-Loop-Schleife) liest die Dateiliste zuerst in ein Datenfeld ein, die zweite Schleife (eine For-Next-Schleife) führt anschliessend die Änderungen durch.

Beispiel (Lösung)
Sub ZeigeDateienNeu()
Dim astrDateien()
Dim intCounter As Integer
Dim strDatei As String
strDatei = Dir("C:\ExcelDaten\*.xls")
Do While strDatei <> ""
    intCounter = intCounter + 1
    ReDim Preserve astrDateien(1 To intCounter)
    astrDateien(intCounter) = strDatei
    strDatei = Dir()
Loop
For intCounter = 1 To UBound(astrDateien)
    MsgBox astrDateien(intCounter)
    SetAttr astrDateien(intCounter), vbNormal
Next intCounter
End Sub

Informationen von Microsoft
XL2000/OFFICE2000: Endless Loop When Macro Modifies Files in a Folder
http://support.microsoft.com/?kbid=254889

[04] Sortierreihenfolge der mit "Dir" ermittelten Dateien entspricht nicht Erwartungen

Wenn Sie die Dir-Funktion von VBA in einer Programmschleife dazu benutzen, um mehrere Dateien eines bestimmten Verzeichnisses zu ermitteln, werden Sie vielleicht feststellen, dass die Reihenfolge der Dateien nicht unbedingt Ihren Erwartungen entspricht.

Problem
Angenommen Sie verwenden die nachstehende Prozedur, um alle xls-Dateien eines Ordners namens "C:\ExcelDaten" zu erhalten.

Beispiel (Problem)
Sub ZeigeDateien()
Dim strDatei As String
strDatei = Dir("C:\ExcelDaten\*.xls")
Do While strDatei <> ""
MsgBox strDatei
strDatei = Dir()
Loop
End Sub

Wenn im Verzeichnis unter anderem eine Datei liegt, deren Name mit einem Unterstrich (_) beginnt (z.B. "_TestDatei.xls"), so erhalten Sie diese Datei erst nach den Dateien, die mit einer Ziffer oder einem Buchstaben beginnen. Die Reihenfolge lautet somit:

1. Dateien, deren Namen mit einer Ziffer beginnen (0*, 1*, ... 9*)

2. Dateien, deren Namen mit einem Buchstaben beginnen (A*, B*, ... Z*)

3. Dateien, deren Namen mit einem Unterstrich beginnen (_*, __*, ___* usw.)

Diese Reihenfolge entspricht nicht der sonst üblichen Reihenfolge in Windows. Wenn beispielsweise im Windows Explorer eine Dateiliste nach Dateiname sortiert wird, so wird folgende Sortierreihenfolge angewendet:

1. Dateien, deren Namen mit einem Unterstrich beginnen (_*, __*, ___* usw.)

2. Dateien, deren Namen mit einer Ziffer beginnen (0*, 1*, ... 9*)

3. Dateien, deren Namen mit einem Buchstaben beginnen (A*, B*, ... Z*)

[05] Verborgene Dateien werden von "Dir" ohne Parameter "Attribute" nicht erkannt

Mit der Dir-Funktion kann sehr einfach die Existenz einer Datei oder eines Ordners geprüft werden.

Problem
Zu beachten gilt, dass die Dir-Funktion lediglich sichtbare Dateien berücksichtigt, d.h. ohne die Konstante vbHidden als Attribute-Parameters ignoriert Dir sämtliche versteckten Dateien und Ordner.

Die folgende VBA-Prozedur erkennt die verborgene Datei "MeineMappe.xls" nicht und gibt daher die Meldung "Datei existiert nicht." aus.

Beispiel (Problem)
Public Sub CheckFile()
If Dir("C:\Dateien\MeineMappe.xls") <> "" Then
MsgBox "Datei existiert."
Else
MsgBox "Datei existiert nicht."
End If
End Sub

Lösung
Wenn sowohl sichtbare als auch verborgene Dateien berücksichtigt werden sollen, muss vbHidden verwendet werden:

Beispiel (Lösung)
Public Sub CheckFile()
If Dir("C:\Dateien\MeineMappe.xls", vbHidden) <> "" Then
MsgBox "Datei existiert."
Else
MsgBox "Datei existiert nicht."
End If
End Sub

Die obige Codezeile prüft die Existenz der Datei "MeineMappe.xls" korrekt, unabhängig davon ob sie verborgen ist oder nicht.

Weitere Informationen

VBA Codebeispiele: Existenz einer Arbeitsmappe vor dem Öffnen prüfen

VBA Codebeispiele: Existenz eines Ordners prüfen

[06] Überprüfen der Datei-Existenz mit "Dir" liefert falsches Ergebnis

Wie bereits erwähnt kann mit der Dir-Funktion die Existenz einer Datei überprüft werden.

Problem
Text folgt...

[07] Probleme mit dem FileSystemObject (FSO) unter Windows XP

Wenn Sie das FileSystemObject unter Windows XP verwenden, so können Probleme auftreten. Einzelne Dateien und Verzeichnisse, wie unter anderem die System Volume Informationen von Windows XP, verursachen einen Zugriffsfehler (Access Violation), sobald eine Anwendung einen Zugriff durchführt.

Some files and directories, such as System Volume Information on Microsoft Windows XP, cause an access violation if an application tries to access them. The error handling code stops looking in a directory when a problem occurs. You must use a different approach if you must have a more robust workaround.

http://msdn.microsoft.com/library/en-us/vbcon98/html/vbconthefilesystemobjects.asp

Windows Script wurde für Windows 95, Windows 98, Windows NT 4.0 und Windows 2000 entworfen.
Wichtig: Damit diese Dateien ordnungsgemäß funktionieren, müssen Benutzer von Windows 95 OSR2 installiert haben oder Microsoft Internet Explorer, Version 4.0 oder höher, ausführen. Benutzer von Windows 95 ohne Microsoft Internet Explorer 4.0 oder OSR2 müssen vor der Verwendung dieser Dateien DCOM installieren.
Benutzer, die Microsoft Windows NT 4.0 verwenden, müssen vor der Verwendung dieser Dateien Microsoft Internet Explorer 3.02 oder Internet Explorer 4.0 installieren.
Benutzer, die Microsoft Internet Explorer 3.02 unter internationalen Versionen von Windows 95 (mit oder ohne OSR2) verwenden, müssen vor der Verwendung dieser Dateien DCOM installieren.
Version 5.5:
http://www.microsoft.com/msdownload/vbscript/scripting.asp

Windows Script wurde für Windows 95, Windows 98, Windows NT 4.0 und Windows 2000 entworfen.
Wichtig: Damit diese Dateien ordnungsgemäß funktionieren, müssen Benutzer von Windows 95 OSR2 installiert haben oder Microsoft Internet Explorer, Version 4.0 oder höher, ausführen. Benutzer von Windows 95 ohne Microsoft Internet Explorer 4.0 oder OSR2 müssen vor der Verwendung dieser Dateien DCOM installieren.
Benutzer, die Microsoft Windows NT 4.0 verwenden, müssen vor der Verwendung dieser Dateien Microsoft Internet Explorer 3.02 oder Internet Explorer 4.0 installieren.
Benutzer, die Microsoft Internet Explorer 3.02 unter internationalen Versionen von Windows 95 (mit oder ohne OSR2) verwenden, müssen vor der Verwendung dieser Dateien DCOM installieren.
Version 5.1:
http://www.microsoft.com/msdownload/vbscript/scripting51.asp

Betriebssystem - Windows 98, Windows NT 4.0, Windows 2000, Windows Me
Version 5.6:
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/733/msdncompositedoc.xml

[08] Probleme mit dem FileSearch-Objekt von Office 97 unter Windows 2000

Für die Durchführung einer Dateisuche kann in Microsoft Office-VBA das FileSearch-Objekt eingesetzt werden.

Problem
Das FileSearch-Objekt von Office 97 funktioniert auf einer Arbeitsstationen mit installiertem Windows 2000 nicht korrekt. Solange Suchmuster für Dateinamen verwendet werden, die nicht die Platzhalter "*" und "?" (sogenannte Wildcards) enthalten, treten allerdings keine Probleme auf. Erst bei Verwendung eines Platzhalters erscheint der Laufzeitfehler 5 "Ungültiger Prozeduraufruf", sobald die Programmzeile mit der FileName-Eigenschaft abgearbeitet wird.

Beispiel (Problem)
Sub SearchFiles()
Dim intCount As Integer
intCount = 0
With Application.FileSearch
    .NewSearch
    .FileName = "*.xls"   '<- Laufzeitfehler Nr. 5
    .LookIn = "D:\Daten"
    .SearchSubFolders = False
    .MatchTextExactly = True
    .FileType = msoFileTypeAllFiles
    If .Execute > 0 Then
      intCount = .FoundFiles.Count
    End If
End With
End Sub()

Das obige Makro schlägt bei Ausführung der markierten Zeile fehlt, wenn es auf einem Windows 2000-PC in einer Office 97-Anwendung ausgeführt wird.

Das gleiche Makro läuft problemlos in Office 2000. Ebenfalls ohne Probleme funktioniert es in Office 97 auf einem PC mit Windows 95, Windows 98, Windows ME, Windows NT 4.0 oder Windows XP.

Lösungsvarianten
Eine eigentliche Lösung zu diesem Problem existiert nicht, da dieser Fehler in Office 97 nie behoben wurde, d.h. es gibt keinen Service-Release/-Pack oder Hotfix für das FileSearch-Objekt. Es können nur Umgehungslösungen angeboten werden:
- Office 2000 oder Office XP verwenden
- Andere Windows-Version als Windows 2000 verwenden
- Dateisuche mittels der Dir-Funktion anstelle dem FileSearch-Objekt durchführen (siehe nächstes Beispiel)

Beispiel (Umgehungslösung mit Dir-Funktion)
Sub SearchFilesWithDir()
Dim astrDateien()
Dim intCounter As Integer
Dim strDatei As String
strDatei = Dir("D:\Daten\*.xls")
Do While strDatei <> ""
    intCounter = intCounter + 1
    ReDim Preserve astrDateien(1 To intCounter)
    astrDateien(intCounter) = strDatei
    strDatei = Dir()
Loop
For intCounter = 1 To UBound(astrDateien)
    MsgBox astrDateien(intCounter)
Next intCounter
End Sub

Hinweis
Das FileSearch-Objekt besitzt noch weitere Fehler und ungewöhnliche Verhaltensweisen. Mehr dazu erfahren Sie hier:

	Weitere Informationen
	VBA-Spezialthema: File Search Object

Informationen von Microsoft
OFFICE97: Microsoft Office 97 Programs FileSearch Fails on a Microsoft Windows 2000-based Computer
http://support.microsoft.com/?kbid=259738 (Dead Link seit 28.11.2002)

[09] Vorlagen-Dialogfenster kann nicht mit VBA geöffnet werden

In Excel 2002-VBA existiert ein Fehler (Bug) bezüglich der Excel-Konstante xlDialogNew.

Problem
Wenn der Vorlagen-Dialog mit der Anweisung

Application.Dialogs(xlDialogNew).Show

aufgerufen wird, hält das Makro nicht an, und auch die vom Benutzer getroffene Wahl wird nicht entgegengenommen.

Lösung
Das hier beschriebene Problem wurde in Office XP Service Pack 1 behoben.

Hinweis
Die oben angegebene Anweisung funktioniert in Excel 97 und Excel 2000 ohne Fehler und öffnet dieses Dialogfenster:

Dialog "Neue Datei basierend auf Vorlage"
Abbildung: Datei neu-Dialog (Neue Datei basierend auf Vorlage erstellen)

[10] Arbeitsblatt kann nicht mit FileFormat xlWorkbookNormal gespeichert werden

Ein einzelnes Arbeitsblatt kann in VBA mit der SaveAs-Methode des Worksheet-Objektes gespeichert werden, wobei mit dem FileFormat-Argument das zu verwendende Dateiformat spezifiziert werden kann.

Problem
Wenn ein Arbeitsblatt mit einem VBA-Makro in Excel 2002 mit dem Standard-Dateiformat "Arbeitsmappe" gespeichert werden soll und das Format durch die Konstante xlWorkbookNormal (Element der Konstantenauflistung "XlFileFormat") angegeben wird, tritt ein Fehler auf. Die Anweisung

ActiveSheet.SaveAs FileName:="EinBlatt.xls", FileFormat:=xlWorkbookNormal

führt zum Laufzeitfehler 1004 "Method 'SaveAs' of object '_Worksheet' failed". Der Grund: Excel 2002-VBA kann die Konstante xlWorkbookNormal nicht korrekt verarbeiten.

Lösung
Wenn anstelle der Konstante xlWorkbookNormal der Wert "1" für FileFormat angeben wird, findet die Speicherung ohne Fehler statt. Die Anweisung

ActiveSheet.SaveAs FileName:="EinBlatt.xls", FileFormat:=1

funktioniert somit problemlos.

Anmerkung des Autors
In der Onlinehilfe von Excel-VBA haben sich ein paar gröbere Fehler eingeschlichen. Betrachten wir zunächst das in der Onlinehilfe enthaltene Beispiel zur FileFormat-Eigenschaft des Workbook-Objektes:

Beispiel zur FileFormat-Eigenschaft

In diesem Beispiel wird die aktive Arbeitsmappe im Standard-Dateiformat gespeichert, falls sie momentan das Dateiformat WK3 aufweist.

If ActiveWorkbook.FileFormat = xlWK3 Then
ActiveWorkbook.SaveAs FileFormat:=xlNormal
End If

In der Codezeile mit dem "SaveAs" ist das FileFormat als "xlNormal" spezifiziert. Ein kurzer Blick auf die integrierten Konstanten im Objektmodell (im Objektkatalog suchen nach "xlNormal") verrät jedoch, dass die Konstante xlNormal gar nicht zur Konstantenauflistung XlFileFormat sondern zur Auflistung XlWindowState gehört! Das ist eigenartig. Die Konstante xlNormal besitzt den Wert -4143. Noch ein Blick auf die Konstantenauflistung XlFileFormat verschafft Klarheit: Die im Codebeispiel angegebene Konstante xlNormal müsste korrekt xlWorkbookNormal heissen, denn xlWorkbookNormal gehört zur Auflistung XlFileFormat und besitzt ebenfalls den Wert -4143.

Aber erinnern wir uns an das eingangs beschriebene Problem, dass xlWorkbookNormal in Excel 2002 zu einem Fehler führt. Gemäss Microsoft muss anstelle xlWorkbookNormal die Zahl 1 angegeben werden, damit korrekt gespeichert werden kann. Wie wir wissen, besitzt die Konstante xlWorkbookNormal den Wert -4143. Wenn die Konstante fehlerhaft ist, wieso muss dann der Wert 1 und nicht der für die Konstante entsprechende Wert -4143 angegeben werden? Ein weiterer Blick in das Objektmodell führt - zumindest für mich - zu einer neuen Überraschung. Wenn man nämlich nachforscht, welche Konstanten den Wert 1 darstellen, so erhält man nur eine sinnvolle Übereinstimmung: es handelt sich um die Konstante xlWorkbook. So weit so gut. Doch ist Ihnen aufgefallen, zu welcher Konstantenauflistung xlWorkbook gehört? Sie gehört zur Auflistung XlWindowType! Das ist äusserst merkwürdig, denn über XlFileFormat und XlWindowState sind wir jetzt bei XlWindowType angekommen. Noch viel merkwürdiger ist, dass sich in der Auflistung XlFileFormat tatsächlich keine Konstante finden lässt, die den Wert 1 besitzt. Wieso dann 1, wenn es gar kein FileFormat mit dem Wert 1 gibt? Ich versteh' die Welt nicht mehr...

[11] Trotz fehlgeschlagenem Speichern wird kein Laufzeitfehler ausgelöst (Excel 2000)

During a file save operation in Microsoft Excel, if a second program locks the file, a temporary file with an eight-character hexadecimal name is created, which contains the saved data, and the original file is deleted. No error message is generated, and when you reopen the file, it reveals data loss.

XL2000: No Error Message Returned to VBA on Failed Save
http://support.microsoft.com/?kbid=269521

Lösung
Das hier beschriebene Problem wurde in Microsoft Office 2000 Service Pack 2 behoben.

[12] Leeres Anwendungsfenster nach "ActivateMicrosoftApp" bei Late Binding mit "New"

Wird eine ganz bestimmte Kombination von "Dim WordApp As New Word.Application" und "Application.ActivateMicrosoftApp xlMicrosoftWord" in der gleichen Prozedur verwendet, führt dies zu einem leeren Anwendungsfenster von Word (siehe Abbildung).

Leeres Anwendungsfenster von Word
Abbildung: Leeres Anwendungsfenster von Microsoft Word

Das Hauptfenster von Word enthält weder die Menüleiste noch irgendwelche Symbolleisten.

Dieses Makro führt zu diesem Phänomen:

Sub OpenWord()
Dim WordApp As New Word.Application
MsgBox WordApp.Application
Application.ActivateMicrosoftApp xlMicrosoftWord
End Sub

Mit der Dim-Anweisung wird die Objektvariable WordApp als Typ "Word.Application" deklariert. Mit dem ersten Zugriff auf WordApp wird das Objekt instanziert und dadurch eine neue Word-Instanz gestartet, die jedoch für den Benutzer nicht sichtbar ist (da Visible = False). Durch das Abfragen der Application-Eigenschaft des Word-Objektes anhand der MsgBox-Anweisung wird der Zugriff durchgeführt. Die ActivateMicrosoftApp-Methode wird zum Schluss dazu verwendet, die bereits laufende Word-Instanz (die allerdings nicht sichtbar ist) einzublenden bzw. zu aktivieren.

Die Ursache des leeren Fenster liegt an der nicht eingeblendeten Word-Instanz. Wäre die Instanz sichtbar, würde das Anwendungsfenster vollständig, mit der Menüleiste und den Symbolleisten, angezeigt. Dieses Makro funktioniert korrekt:

Sub OpenWord()
Dim WordApp As New Word.Application
MsgBox WordApp.Application
WordApp.Visible = True
Application.ActivateMicrosoftApp xlMicrosoftWord
End Sub

[13] Fehler 429 bei "GetObject"-Funktion nach Starten einer Anwendung mit "Shell"

Wenn eine Anwendung mit der Shell-Funktion gestartet und unmittelbar danach versucht wird, anhand der GetObject-Funktion die neu gestartete Instanz zu übernehmen, kann der Laufzeitfehler 429 "Objekterstellung durch ActiveX-Komponente nicht möglich" auftreten.

Hinweis
- Dieses Verhalten tritt bei allen Office-Versionen (Office 97/2000/XP), bei Visual Basic 5.0/6.0 und unter allen Windows-Versionen auf.
- Die hier vorgestellte Ursache des Laufzeitfehlers 429 "Objekterstellung durch ActiveX-Komponente nicht möglich" ist im Thema "Laufzeitfehler 429" der VBA-Referenz (Onlinehilfe) nicht beschrieben.

Problem
Text folgt...

'Deklaration der benötigten API-Routinen
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName as String, ByVal lpWindowName As Long) As Long
Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(ByVal hWnd as Long, ByVal wMsg as Long, ByVal wParam as Long, ByVal lParam As Long) As Long

Sub DetectExcel()
   Const WM_USER = 1024
   Dim hWnd As Long
'Wenn Excel ausgeführt wird, wird durch Ausführen dieses
   'API-Aufrufs die zugehörige Zugriffsnummer zurückgegeben.
   hWnd = FindWindow("XLMAIN", 0)
   If hWnd = 0 Then    '0 bedeutet, dass Excel nicht ausgeführt wird.
      Exit Sub
   Else
      'Excel wird ausgeführt. Verwenden der API-Funktion SendMessage,
      'um Excel in der Tabelle ausgeführter Objekte einzutragen.
      SendMessage hWnd, WM_USER + 18, 0, 0
   End If
End Sub

	Tipp
	Excel 97

Although the Office application is running, it might not be registered in the Running Object Table (ROT). A running instance of an Office application must be registered in the ROT before it can be attached to using GetObject (Visual Basic) or GetActiveObject (Visual C++).

When an Office application starts, it does not immediately register its running objects. This optimizes the application's startup process. Instead of registering at startup, an Office application registers its running objects in the ROT once it loses focus. Therefore, if you attempt to use GetObject or GetActiveObject to attach to a running instance of an Office application before the application has lost focus, you might receive one of the errors above.

RESOLUTION

Using code, you can change focus from the Office application to your own application (or to some other application) to allow it to register itself in the ROT. Additionally, if your code is launching the Office application's exe file, you might need to wait for the Office application to finish loading before attempting to attach to the running instance. A code sample is provided as a workaround in the "More Information" section below.

STATUS

This behavior is by design.

PROBLEM: GetObject or GetActiveObject Cannot Find Office Application
http://support.microsoft.com/?kbid=238610

[14] Programmcode im "BeforeSave"-Ereignis führt zum Absturz des VBA-Editors

Beschreibung folgt...

XL97: Crash Saving Workbook That Uses BeforeSave Event
http://support.microsoft.com/?kbid=177393

[15] Blatt-Aktivierung im Workbook_Open-Ereignis unmöglich (Excel 97)

Beschreibung folgt...

Private Sub Workbook_Open()
  Sheet2.Activate
End Sub

XL97: Open Event Macro May Not Activate a Worksheet
http://support.microsoft.com/?kbid=174319
Dieser Fehler verunmöglicht eine korrekte Blatt-Aktivierung im Workbook_Open-Ereignis. Das Problem lässt sich nur durch Verwendung eines Auto_Open-Makros lösen, da es erst in Excel 2000 behoben wurde.

[16] Saved-Eigenschaft enthält "True" trotz Abbruch des Speichern-Vorganges (Excel 97/2000)

Die Saved-Eigenschaft besitzt meiner Meinung nach einen Fehler, da sie in einer bestimmten Situation fälschlicherweise den Wert "True" anstelle "False" enthält. Dieses fehlerhafte Verhalten tritt auf, wenn der Speichern-Vorgang nicht vollständig durchgeführt werden konnte. Das heisst, dass durch Excel die Eigenschaft Saved auf den Wert "True" gesetzt wird obwohl die Datei nicht ordnungsgemäss gespeichert wurde.

Weitere Informationen zu diesem Problem finden Sie hier:

Weitere Informationen

Excel-Objektmodell: Eigenschaften des Workbook-Objektes

Fehlermeldungen: Fehlermeldungen beim Speichern einer Arbeitsmappe

[17] Arbeitsspeicher-Probleme beim Einsatz des "FileSearch"-Objektes von Office 97 (Office 97)

An dieser Stelle möchte ich auf ein Problem aufmerksam machen, das bei mir in Microsoft Excel 97 unter Windows NT 4.0 auftritt und beliebig oft reproduziert werden kann.

Excel-Dialogfenster "Datei öffnen"

Sub DoFileSearch()
  With Application.FileSearch
    .FileName = "*.xl*"
    .SearchSubFolders = True
    .TextOrProperty = "fso"
    .Execute
  End With
End Sub

[18] Aktualisierung der LookIn-Eigenschaft des FileSearch-Objektes erfolgt erst nach Excel-Neustart

[19] Makrostart mit Application.Run führt zu Excel-Absturz

Durch Zufall habe ich einen Fehler bei der Run-Methode des Application-Objektes von Excel entdeckt. Als gewissenhafter VBA-Programmierer werden Sie vermutlich nie die Auswirkungen dieses Fehlers spüren; ganz ausschliessen kann man dies jedoch nicht. Aus diesem Grund hier eine kurze Fehler-Beschreibung.

Mit Application.Run (beziehungsweise nur Run) kann ein Makro gestartet werden, welches sich in der gleichen Mappe wie die Run-Methode befindet oder in einer anderen Arbeitsmappe liegt.

Application.Run

Weitere Informationen

Excel-Objektmodell: Eigenschaften des Workbook-Objektes

Fehlermeldungen: Fehlermeldungen beim Speichern einer Arbeitsmappe

Hinweis
Auch in VBA von Microsoft Word steht Application.Run zur Verfügung. Die Implementierung dieser Methode scheint in Word jedoch einiges besser zu sein, da ich den oben beschriebenen Fehler nicht reproduzieren konnte. Wird in Word-VBA der Name des auszuführenden Makros weggelassen, meldet der VBA-Editor sofort "Fehler beim Kompilieren: Argument ist nicht optional".

Hinweis
Weitere Informationen zu Application.Run und anderen Methoden und Eigenschaften im Excel-Objektmodell finden Sie hier.

[20] Verschieben des einzigen Arbeitsblattes in andere Arbeitsmappe schliesst Datei ohne Speicherung

Ein äusserst interessantes Verhalten tritt beim Verschieben des einzigen Arbeitsblattes bzw. aller Arbeitsblätter einer Mappe in eine andere Arbeitsmappe auf.

Workbooks("Mappe1").Worksheets(1).Move Workbooks("EineMappe.xls").Worksheets(1)

[21] Kopieren eines ausgeblendeten Arbeitsblattes in eine neue Mappe führt zu Excel-Absturz

Beitrag folgt...

ActiveSheet.Copy

Haben Sie Fragen, Anregungen oder Hinweise?
Senden Sie mir ein Mail