| |
|
|
Thomas Freier | Im Moment bin ich mit meiner Lösung nicht glücklich, da sie nicht absulut hinhaut. Ich starte eine Office Anwendung, und wenn die beendet ist, soll ein PDF-Reader starten. KompilierenMarkierenSeparieren geift nicht. Jedenfalls bei mir mit Portable OpenOffice 2.2 Es wird sofort der PDF-Reader gestartet. Alternativ frage ich, ob die mit Ooo geöffnete Datei zur weiteren Bearbeitung geöffnet werden kann. KompilierenMarkierenSeparieren Aber selbst das "Sleep 10000" reicht manchmal nicht, bis Ooo sich eingerichtet hat und auf die Datei zugreift. Ins Besondere, wenn alles auf einem USB-Stick läuft.
Gibt es eine eine elegantere Lösung? |
|
|
| |
|
|
|
| Schau mal zu WinExec: Hilfe
Seit Version 11 liefert die Funktion die Prozeß-ID des gestarteten Programmes zurück, wie es im Taskmanager angezeigt wird. Im Fehlerfall ist es der Wert 0. Bei früheren Versionen war der Wert im Erfolgsfall ohne Bedeutung.
Dann mal schauen was GetExitCode(ProzessID) zurückliefert - vlt. hilft das schon.
Speziell von OpenOffice weiß ich aber das dies mit den Prozessen selbst schon herumspielt - also manch Prozess nur andere startet oder benachrichtigt und sich selbst aber dann gleich wieder beendet - hier bleibt dann vlt. nur eine an OO angepasste Lösung wie z.B. FensterFinden etc. . |
|
|
| |
|
|
|
Paul Glatz | Starte mal beim Portable nicht die normale exe sondern die unter APP |
|
|
| |
|
|
|
Thomas Freier | @Paul, das habe ich schon getestet und hat keinen Einfluß bei: "@WinExecWait(Prog$,1)" @iF, mit: KompilierenMarkierenSeparieren brachte nichts. Möglich, dass 256 nicht richtig ist.
Nachtrag: hat jemand Erfahrung beim Umbennen von odt-Dateien mit XProfan? KompilierenMarkierenSeparierenführt immer dazu, dass Ooo eine "beschädigte" Datei wiederherstellen will. |
|
|
| |
|
|
|
| @Thomas: Ja, habs vermutet - OO nutzt manch Prozess nur um einen anderen zu benachrichtigen. Ich wüsste jetzt nur noch mal mit AddWindows/ FindWindow zu schauen ob man es daran irgendwie "festmachen" kann. |
|
|
| |
|
|
|
Thomas Freier | @iF: das mit FindWindow vermute ich, wenn ich das nicht schon als erstes getestet hatte, endet wie mit dem Test, die an Ooo übergebene Datei zu öffnen. D.h. der Fenstertitel ist erst komplett vorhanden, wenn die Datei geöffnet wurde. Also n-Zeit warten bis der Fenstertitel abfragbar ist. |
|
|
| |
|
|
|
| >> Also n-Zeit warten bis der Fenstertitel abfragbar ist.
Oder einfach "warten bis der Fenstertitel abfragbar ist" also while not fenster da warten... |
|
|
| |
|
|
|
| Vlt. hilft Dir auch eine Prozesse-Liste: [...] |
|
|
| |
|
|
|
Thomas Freier | |
|
| |
|
|
|
| Genau, PID ist die Prozess-ID - wenn der Prozess aber bereits beendet ist dann wird er auch nicht mehr in der Liste stehen.
Drum meinte ich ja: "also manch Prozess nur andere startet oder benachrichtigt und sich selbst aber dann gleich wieder beendet"...
Vielleicht aber nutzt es Dir eine Liste aller Prozesse nach Openoffice-Prozessen zu durchsuchen um zu schauen ob überhaupt noch eins aktiv ist oder nicht. |
|
|
| |
|
|
|
Thomas Freier | Ich werde noch einmal den Weg über
Oder einfach "warten bis der Fenstertitel abfragbar ist" also while not fenster da warten... und dann, wenn gefunden mit zweiter Schleife while not fenster =weiter, versuchen. Muß dann aber den möglichen Fensternamen der Anwendungs.exe, da frei wählbar und die Basis immer die soffice.exe ist, für StarOffice (Fenster = 02-27.odt - StarOffice 8) und bei OpenOfice (Fenster = 02-27.odt - OpenOffice.org Writer) festlegen.
Ach, könnte man diesen Office-Hackern doch Scribus näher bringen. Da kann man eine PDF und eine PNG von dem Dokument erstellen.
|
|
|
| |
|
|