Office: (Office 2003) Haltemodus fallweise unterdrücken

Abseits von Code & Co. könnte man darüber nachdenken, ob man seine Dokumentenverwaltung so attraktiv für den Benutzer aufbaut, dass er seine Dokumente lieber immer über diese Dokumentenverwaltung öffnet (und so bekannte Verhältnisse schafft) statt frei.

Da wäre dann ein "Nichtfunktionieren" in der zweiten Variante leicht zu übergehen.

 

Wie soll man es anders nennen als Verwaltung??? Relevante Dokumente sollen sichtbar gemacht und bearbeitet werden können. D.h. beim Klcik auf ein Item soll das Dokument in Word geöffnet werdne oder angezeigt, wenn es schon offen ist.

Das sehe ich eigentlich wie @anne. Meine bisherigen Test haben ergeben, das Word alles "zusammen pappt". Mehrere Dokumente werden in einer Instanz zusammen gefasst. Dennoch hast auch DU recht.. wer weiss , was alles passieren kann.

Genau das mache ich doch schon. Davon ausgehend, das wirklich nur eine Instanz offen ist, was IMHO der Regelfall sein sollte:

Beim einlesen der Dokumente werden diese in eine Collection gelegt und die bestehende Word-Instanz wird einer Member-Objetvariable einer Klasse zugewiesen. Innerhalb der Klasse reagiere ich auf die Ereignisse der WordInstanz. Zb. BeforeDocumentClosed. Hier wird zB. angewiesen, das das Dokument, welches geschlossen wird, aus der Collection entfernt wird. Bei 'DocumentOpen' wird das Document wieder in die Collection geaddet. Wenn ich aus der Access-Anwendung heraus ein Document öffne, wird diese auf dem gleichen Wege behandelt und landet in der Collection. Und auf Basis der Collection navigiere ich zwischen den Dokumenten.

Dem stimme ich zu. Nur leider fand ich bezüglich der aktuellen Problemstellung immer wieder nur Lösungen wie in #1 gepostet.
Ehrlich gesagt graust es mir ein wenig davor, mich mit dieser WMI-Geschichte rum zu schlagen. Andererseits würde ich dort die Möglichkeit sehen, auch mehrere Instanzen von Word zu erkennen

 

\@Anne,

ich bin bis heute nicht einmal drauf gekommen, das ich in dem Falle über die Tastenkombination unterbrechen kann. Wieder was gelernt. Danke *Smilie

 

Nicht ganz. Aus genannten Gründen verwendest Du GetObject zum Prüfen, ob eine Instanz vorhanden ist. Mein Gedanke da war aber GetObject dann einzusetzen, wenn man weiß, dass es eine offene Instanz gibt.

Eine Kurzrecherche brachte u.a. folgenden Vorschlag, um zu prüfen, ob eine bekannte Anwendung läuft und somit eine aufzunehmende Instanz haben sollte: Prüfen, ob eine EXE-Datei ausgeführt wird

 

Zum Thema Wordinstanzen:
Mit dem Parameter /x lassen sich mehrere Instanzen problemlos öffnen.
Sprich WinTaste-R (ausführen) -> winword.exe /x und schon gibt es eine neue Instanz.
Weiter kann ich mich an Konstellationen erinnern, bei denen ein Worddokument über ein Webbrowsercontrol geöffnet wurde und Word dies ebenfalls in einer eigenen Instanz öffnete.
Nächster Punkt: Word ist in der bestehenden Instanz beschäftigt (z.B. offener Dialog) und aus einem Browser wird eine Worddatei geöffnet -> neue Instanz
Und noch einer: Ein Worddokument wird embedded in einer Webseite dargestellt -> eigene Instanz

Das sind so die Punkte die mich in meinem Umfeld schon ereilten *Smilie

Nach Post #17 kann ich Dir nur empfehlen all das in einer eigenen Instanz zu tun. Die Ereignisse die Du abfängst bzw. auf die Du reagierst sind ja nicht Dokumentbezogen und somit nur für Dokumente von Dir in der gemeinsamen Instanz gültig, sondern für alles was innerhalb dieser Instanz passiert. Das kann u.U. zu unschönen Nebeneffekten führen (z.B. ein Dokument in Deiner Collection das dort eigentlich gar nix zu suchen hat)

 

Danke @Eberhard für den Link und danke @Benny für die Hinweise.

Ich werde erst noch einiges austesten und mich nochmal hier melden.

 

Hallo und schönen Samstag,

Ich hab mich nochmal mit dem zukünftigen Anwender kurzgeschlossen.
Was ich bisher nicht deutlich zum Ausdruck gebracht habe... die sogenannte Dokumentenverwaltung steht ausschließlich im Kontext mit der Kundenverwaltung, die ich schon soweit fertig und übergeben habe. Die entsprechenden Dokumente liegen in ein und dem selben Ordner und sollen ausschließlich über die anzuschließende Dok-Verwaltung modifiziert werden. Mit dem Anwender bin ich erstmal so verblieben, das nur bereits geöffnete Dokumente aus dem gemeinsamen Ordner ggf. mit eingebunden werden.

Daher hab ich jetzt folgenden Weg entwickelt.

Für ein Listview muss ich ohnehin die Dateien aus dem Ordner einlesen. Dabei prüfe ich jede Datei darauf, ob sie bereits geöffnet ist. Ist dies der Fall, prüfe ich weiterhin, ob der Dateiname in den Tasks des Rechners zu finden ist. Ist dies der Fall hole ich mir ein Objekt davon und adde es in eine Collection (zur weiteren Verarbeitung).

Zudem gedenke ich alle so gefundenen Dokumente in und mit ihrer ursprünglichen Instanz zu schließen und über eine eigene Instanz neu zu öffnen. Eine bestehende Instanz werde ich nicht mehr übernehmen. Es ist auch nicht davon aus zu gehen, das der Anwender unzählige Dokumente offen hat, sobald die Anwendung gestartet wird. Das Manöver soll eher eine bequeme Maßnahme sein, evtl. vergessene Dokumente nicht erst separat aufrufen und schließen zu müssen etc.

Meine Version, die Tasks zu durchsuchen, scheint mir ein wenig langsam. Ich nutze dazu momentan das Task-Object eines Word-Objektes. Bevor ich diese näher vorstelle aber erstmal folgende Frage:

Kann man grundsätzlich davon ausgehen, das jede geöffnete Instanz mit oder ohne den enthaltene Dokumente mit eigenem Task im System geführt wird oder gibt es auch da wieder Fallstricke??????

 

Solches Tiefenwissen gewinnt man eigentlich nur durch Dauertesten von Umgebungen, die man - weil man sein Köpfchen einsetzt - nie verwenden wird. Ich würde aber sagen ja. Prozesse siehst Du im Taskmanager. Wenn da kein Prozess läuft, dürfte es auch nicht zugehörige geöffnete Dokumente geben.

Dass er (der Anwender) vor dem Erfassen der Dokumente einfach mal sein Word schließt bzw. vor der Maßnahme Erfassen Word mit irgendetwas noch nicht geöffnet hat - so was kriegt er wohl nicht in die Reihe?

Da staunt man ja, wie die einfach so geöffnet sein können ...

 

Vorweg.. wenn die ganze Sache nicht vernünftig und sicher zu programmieren ist, dann wird sich der Anwender auch damit begnügen, ggf. geöffnete Dokumente zuvor zu schließen. Im Moment würde ich die Diskussion gerne unter dem Gesichtspunkt fortführen, dass ich meinen Horizont erweitern will.

Warum sind dann solche .. zB Task-Objekte verfügbar, wenn man sie nicht einsetzen soll? Sicher... man muss nicht alles machen was möglich ist, nur... (mal unabhängig von meiner aktuellen Problematik), wie finde ich heraus, welche Dateien evtl. geöffnet sind und vor allem.. in welcher Instanz? Auf eine ausgeführte Exe zu prüfen, sagt mir nur, ob eine Exedatei gestartet ist. GetObject kann man, wenn das Dokument nicht geöffnet ist, nur über eine Fehlerbehandlung abfangen. Zudem muss man auch wissen, in welcher Instanz ein Dokument geöffnet ist und selbige ansprechen können. Ich hab aber bisher keinen Weg gefunden, ohne GetObject in der 'Running Object Table' nach geöffneten Dokumenten zu fahnden, oder aber die offenen Wordinstanzen anzusprechen und deren Documentsauflistung durch zugehen.
Daher meine Idee über die Taskauflistung nach dem Dateinamen zu suchen, weil dann (wenn die Datei dort verfügbar ist), auch die GetObject-Methode erfolgreich sein müsste.

Der Anwender ist doch mündig... er könnte ggf. Dokumente separat in Word öffnen. Und danach seine Kundenverwaltung starten. Man kann das alles reglementieren und gut möglich, das ich das auch noch mache. aber im Moment möchte ich es halt für mich heraus finden

 

Naja, das war nur ein Gedanke. Für mich hat das Wort "ausschließlich" eine eindeutige Bedeutung: ausschließlich = 100 Prozent, sonst liegt eine Lüge vor.

Von nicht soll war nie die Rede. Ich halte es wie Benny oben orientiert hat: Meine Anwendung würde für ihre Bedürfnisse (genau) eine eigene neue Instanz für Word verwenden, und alle anderen interessieren mich dann nicht. Somit mache ich es mir einfach und muss nicht überall nach irgendetwas suchen.

Kleiner Seitensprung: Ich betreue auch eine Kundenverwaltung mit anhängender Dokumentenverwaltung. Dabei befinden sich in einem Oberordner Kundendokumente pro Kunden einzelne Ordner, in die der Benutzer wie auch die Anwendung zugehörige Dateien ablegt: XLS, PDF, DOC, JPG, MSG und was er will.
Aus der Kundenverwaltung heraus wird nur der zugehörige Kundenordner in einem neuen Explorerfenster geöffnet. Dort kann sich der Benutzer dann nach Belieben bedienen. Da für Dateibezeichnungen ein Bezeichnungsregime eingeführt wurde (Erstellungsdatum + Kurzbeschreibung Inhalt), ist der gezielte Zugriff sehr einfach.
Um den Rücksprung zu schaffen: Der mündige Benutzer wird nun diejenigen Dokumente, die verwaltet werden sollen, schlicht in diesen Kundenordner ablegen. Und meine Anwender tun dies gerne (ohne Reglement), weil sie so ihre Dateien sehr schnell und besser als sonst wiederfinden.
Eine Suche oder Erfassung wie auch immer laut Deiner Aufgabenstellung ist da unnötig.
In diesem Sinne ist auch mein obiger Hinweis bzgl. VerwaltungZugriff zu verstehen. Verwaltung heißt da: Ich biete ein Explorerfenster, wo die gesuchten Dateien liegen, und von der Anwendung erstellte Dateien werden (als Standardvorbelegung) dort abgelegt. Der Zugriff (i.d.R. Öffnen durch Doppelklick) interessiert die Anwendung nicht.

Das geht m.W. nicht.

Statt zu prüfen, ob Word läuft (siehe Link oben) kann man auch auch die Prozess-ID's und damit die Instanzen ermitteln: Handle einer gestarteten EXE-Datei ermitteln.
Aus gerade dargestellten Gründen habe ich aber hiermit keine praktischen Erfahrungen, sprich üben musst Du selber.
Wenn Dir umgedreht der Pfad eines offenen(!) Dokumentes bekannt ist, kannst Du mit GetObject die Referenz des Dokumentes ermitteln und über diese an die Referenz zur zugehörigen Instanz kommen, etwa ...
Code:

 

Hallo Uwe,

dieses "Problem" habe ich ganz früher auch gehabt. Inzwischen bin ich bei den Gedanken des Clean Coding angekommen. Seither schreibe ich statt einer großen Prozedur, die alles auf einmal erledigt viele kleine Prozeduren, die jeweils eine konkrete Aufgabe erledigen.
Ich solch einem Umfeld erkennst Du häufig schon aus der Fehlermeldung die Zeile, in der der Fehler auftritt. Ansonsten startest Du das schrittweise ausführen in der ersten Zeile der Prozedur. Da diese ja nur noch wenige Zeilen hat, bist Du so schnell beim Fehler.

CU

 

Moin Moin,

der Gedanke des 'Clean Coding' ist mir quasi schon selbst gekommen, auch wenn ich erst jetzt durch @Thomas darauf gestoßen bin. Für mich als bekennenden Chaoten ist das extra wichtig, weil ich allzu oft schon festgestellt habe, dass ich in meinem eigenen Code nicht mehr durchsehe. Dies hat sich gegeben, weil ich von mir aus angefangen habe, strukturierter zu arbeiten und Prozeduren wo immer es mir möglich und sinnvoll erschien, in mehrere kleine aufzuteilen. Es hilft ungemein.

Nochmal zur Fehlerbehandlung.
Ich habe Eure Meinungen/Arbeitsweisen zur Kenntnis genommen. Selbst habe ich bisher, außer der Problematik in #1 keinen Code, in dem ich die Fehlerbehandlung zur Problemlösung nutze. Was also spricht gegen meine Arbeitsweise, also die Einstellung 'bei jedem Fehler'??? Wie gesagt, ich schätze es sehr, bei eintreten eines Fehlers immer direkt in die Fehlerzeile geleitet zu werden.

Gesamtproblematik:
Anwender und ich sind jetzt bei dem Stand, das evtl. geöffnete Dokumente (im Kontext zur DB-Anwendung) gespeichert und ggf. mit samt der zugehörigen Word-Instanz geschlossen werden. Das Ganze soll eine Sicherheitsmaßnahme sein. Da aber die Dokumente auf einem Server liegen ist es denkbar, das ein Dokument nicht auf dem aktuellen Client geöffnet ist, sondern auf einem anderen.

Vorgehensweise:
1. Einlesen des Dokumentenordners zur Darstellung in einem Listview. Dabei wird erst geprüft, ob Dateien bereits geöffnet sind. Wenn ja, werden diese zwischen gespeichert.
2. Einlesen der, auf dem aktuellen Client ggf. geöffneten, Dokumente über alle evtl. geöffneten Wordinstanzen und ebenfalls Zwischenspeicherung.
3. Abgleich der Listen aus 1 und 2
4. Dokumente die geöffnet sind, sich aber nicht in der Liste aus 2 befinden, werden für den weiteren Zugriff gesperrt.
5. Dokumente die geöffnet sind und sich in der Liste aus 2 befinden werden wie folgt weiterbehandelt:

a) Mittels GetObject wird das Dokument instanziert (da das Dokument ja tatsächlich in Word geöffnet ist, kann GetObject keinen Fehler mehr schmeißen)
b) Die Parent-Eigenschaft des Dokumentes wird als temporäre Wordinstanz instanziert
c) Das Dokument wird mit der Option Save = True geschlossen
d) Die 'Documents.Count'-Eigenschaft des zuvor instanzierten Wordinstanz wird auf '=0' geprüft. Bei True existieren in der Instanz keine Dokumente mehr und Word kann somit geschlossen werden, bei False sind in der Instanz noch Dokumente offen. Dieses wiederholt sich, bis die Liste abgearbeitet ist. Wenn danach noch Dokumente in der Instanz offen sind, ist davon aus zu gehen, dass diese mit dem DB-Kontext nicht zu tun haben. Da aber in diesem Fall die Wordinstanz nicht geschlossen wird, bleiben also Dokumente außerhalb des DB-Kontextes von dem Procedere unberührt.

Zu Punkt 2.
Nach eingehender Recherche im Netz bin ich auf folgenden interessanten Beitrag gestoßen.

http://www.office-loesung.de/viewtopic.php?t=525840 .

Ich habe erfolglos versucht, diese Lösung auf Wordinstanzen anzupassen, so dass schlussendlich die Autorin des Beitrags dieses für mich übernommen hat. Das Ergebnis:

http://www.office-loesung.de/viewtopic.php?t=586949 .

Diese Lösung sucht mittels API-Funktionen nach geöffneten Wordinstanzen und den dort geöffneten Dokumenten.

 

Ich verstehe immer noch nicht, wieso Du Dich dagegen wehrst (oder es nicht möglich sein soll) immer mit einer eigenen Instanz von Word zu arbeiten.

Damit löst Du doch die Probleme, oder nicht?

Wenn Deine DB die Hoheit über die Dokumentenverwaltung hat, dann sollte auch alles daraus passieren und nicht über irgendwelche Umwege die Du dann absichern musst.

 

Woraus schließt DU das jetzt? Genau das ist doch jetzt der Plan/Fall. Hab ich mich unglücklich ausgedrückt?

Was ich unter d) meinte ist, das ich Worddokumente und deren Instanzen unberührt lasse, deren Thema nichts mit der Datenbank, bzw. der von dort geführten Korrespondenz zutun hat.

Db-bezogene Korrespondenz wird, sofern sie wirklich mal geöffnet sein sollte, gespeichert und geschlossen. Ein neuerlicher Aufruf erfolgt dann ausschließlich in einer eigenen Instanz

 

Wenn Du immer mit einer eigenen Instanz arbeitest, brauchst Du kein GetObject.
Ergo brauchst Du auch keine Prüfung auf Error 429 (den ich persönlich in dem speziellen Fall für vertretbar/duldbar halte).

Dir geht es offenbar darum mögliche manuelle Aufrufe der zu verwendenden Dokumente mit zu bekommen um diese ggf. vorher zu schließen, richtig?

Dürfen die Dokumenten denn überhaupt manuell geöffnet werden?
Wenn ja, wäre es möglich z.B. über ein WordAddIn das zu überwachen und z.B. eine Liste der offene Dokumente irgendwo zu speichern.
Wenn nein, organisatorisch klären!