Office: Automatisierungsfehler

Hallo zusammen,

Wie bereits fälschlicherweise in einem anderen Thread gefragt, geht es hier um eine Fehlermeldung die ich erhalte, wenn ich den folgenden Code ausführe.

Code:

Hier ein Ansatz von EarlFred:

Die genaue Fehlermeldung lautet: "Automatisierungsfehler. Das aufgerufene Objekt wurde von den Clients getrennt". Wie EarlFred vermutet, tritt es dann auf, wenn eine Datei des gewählten Namens bereits vorhanden ist. Seltsam ist dann doch aber, dass ich es im schrittweise debuggen speichern kann, ohne eine Fehlermeldung und ein daraus resultierendes Abstürzen herbeizuführen.

Vielen Dank für die schon geleistete Hilfe im anderen Thread und auch im Voraus für die Hilfe hier!

Viele Grüße
Till

:)

 

Wie schon im Zitat angesprochen: Gehe das anders an.
Die Funktion DateiSpeichern macht auch nicht das, was der Name besagt. Und eine Funktion sollte genau das tun, was sie sagt.
Oder Was würdest Du von der folgenden Funktion erwarten
Code:

Triviales Beispiel, aber genau das machst Du.

 

Dann ist das aber keine Absicht von mir! Das Ziel der Funktion ist es, dass sich ein Fenster zum Speichern öffnet und ich dann einfach einen Namen auswähle oder eine schon vorhandene Datei anklicke und das übergebene Workbook dann unter diesem Namen an dem gewählten Ort speichere.

 

Ob Absicht oder nicht ist ja nicht die Frage.

Warum hast Du denn ein Datei schliessen drin, wenn Deine Anforderung ist, die Datei unter einem anderem Namen zu speichern. Dafür reicht der Dialog "Save As" doch aus.

 

Folgende Situation. Der Nutzer lässt sich eine bestimmte Liste ausgeben. Diese soll halbautomatisch gespeichert werden. Der Nutzer sieht das Fenster und kann einen Speicherort und einen Namen wählen, oder er nutzt die vorgegebenen Angaben und klickt nur noch auf Speichern bzw. klickt ENTER.
Das DateiSchließen soll, so habe ich gedacht, lediglich verhindern, dass die neue Datei unter dem Namen einer geöffneten Datei gespeichert wird, da das nicht möglich ist. Also schließe ich diese, falls vorhanden und speichere dann die neue Datei unter dem gewählten Namen.

Es wundert mich ziemlich, da es einige Zeit funktioniert hat und auch jetzt noch im Einzelschritt funktioniert.

 

Die Überprüfung erledigt SaveAs für Dich. Ich würde eine geöffnete Datei nicht einfach schließen, sondern das dem User überlassen.

 

Könntest du mir das denn kurz anhand eines Codeschnipsels zeigen? Ich stehe etwas auf dem Schlauch.

Muss ich dann innerhalb meiner Funktion - wie EarlFred angerissen hatte - anstatt Execute SaveAs verwenden? Wie weiß ich dann, wie der Nutzer die Datei genannt hat und wohin ich sie speichern soll?

 

Code:

Das wkb.close habe ich rausgenommen, denn das ich würde von der Funktion nicht erwarten, dass sie die Datei auch schliesst. Und wenn der User in eine geöffnete Datei speichern will, machst Du eben nichts.

 

Hallo Till,

ich schrieb es eigentlich schon einmal im anderen Thread:

Fall 1:
Du nutzt Deine Sub, um die Datei "Dat1" nochmal unter dem gleichen Namen zu speichern. Deine Sub DateiSchließen() schließt die Datei "Dat1" aber einfach vor dem Speichern. Die Datei, die der Dialog speichern sollte, ist also nicht mehr da. Kein Wunder, dass sich der Code da wundert.

Fall 2:
Du nutzt Deine Sub, um die Datei "Dat2" unter dem Namen "Dat1" zu speichern, "Dat1" ist offen. Deine Sub DateiSchließen() macht "Dat1" also zu, unmittelbar versuchst Du, die andere Datei als "Dat1" zu sichern. Das überschneidet sich womöglich zeitlich (ggf. Vorgang im Dateisystem nicht abgeschlossen - keine Ahnung, was da genau hakt), wie Lupo im anderen Thread vermutet hat. Wenn man beim schließen der Datei eine kleine Wartepause einlegt (1 Sekunde reicht bei mir auf der lokalen Festplatte, im Netz möglicherweise nicht ausreichend, musst Du testen.), funktioniert der Ablauf.

Also:
Fall 1 MUSST Du programmatisch abfangen, indem Du vergleichst, ob wkb.Fullname .SelectedItems(1) und nur dann die Sub DateiSchließen startest.
Fall 2 konnte ich mit Application.Wait regeln. Andere von mir getestete Verfahren erzeugten ebenfalls Abstürze. Sonderlich ausgiebig habe ich aber nicht getestet.

Favorit: Da bin ich gleicher Meinung wie Storax: Wenn die andere Datei bei Dir (oder woanders, wenn Du im Netz arbeitest) offen ist, weise den Nutzer darauf hin. Wenn die Datei frei ist, kannst Du sie überschreiben. Alternative Codeidee: Function DateiGeoeffnet

Grüße
EarlFred

 

Vielen Dank für Eure Rückmeldungen! Ich habe es nun wie folgt gelöst und dabei Eure Ideen mit einfließen lassen. Ich schließe keine Dateien mehr, ohne den Nutzer zu fragen. Ich nutze jetzt eine MsgBox mit VbYesNoCancel und reagiere dann je nach Wahl des Nutzers.

Es kommt nicht mehr zu Abstürzen und ist zudem, von meinem Gefühl her, angenehmer zu bedienen.

Code:

Zu deinem Vorschlag EarlFred

Kannst du mir die Zeilen
Code:

vielleicht kurz erklären? Wenn ich diese nutze, bekomme ich die Fehlermeldung:

"Laufzeitfehler 70 - Zugriff verweigert"

 

Guten Morgen, Till,

die Onlinehilfe zur Open-Anweisung hast Du gelesen? Du weißt also grundsätzlich, was die Anweisung tut und was die Argumente bewirken. Gut.

Genau das ist gewollt, wenn Du die Funktion als ganzes betrachtest und nicht nur die beiden Codezeilen aus dem Kontext reißt.
Wenn Du versuchst, auf eine geöffnete Datei exklusiven Zugriff zu erhalten, wird das einen Fehler erzeugen. Im Umkehrschluss weißt Du, dass die Datei offen sein muss.

Die Funktion als ganzes gibt Dir also (halbwegs) zuverlässig die Antwort auf die Frage, ob die Datei offen ist (wie der Funktionsname andeutet).

Grüße
EarlFred

 

Aufgrund deines Hinweises im anderen Thread ist mir aufgefallen, dass ich das, was ich dachte geschrieben zu haben, anscheinend doch nicht gepostet hatte.
Das Problem bestand lediglich darin, dass ich beim Übernehmen der Funktion das "On Error Resume Next" vergessen hatte.

Danke für Eure Hilfe!

(Wie genau schließe ich denn einen Thread?)