---

Hallo,
Ich habe das Problem, das unter der Verwendung des RUN Befehls mir nicht klar ist, was WorkManager nun wirklich an Windows übergibt.

Wir haben einen Prozess des Datei Importes, der uns aus nach einer Dateiauswahl im WorkManager ein ZIP File erstellt und dieses ZIP importiert. Unter Win2K funktioniert dies sauber.
Momentan testen wir Windows XP und da bekomme ich das einfach nicht hin, denn unter XP haben wir nun eine englische Installation, deshalb C:\Program Files statt C:\Programme.
Ich muss nun ein " vor unt hinter dem Winzip Befehl reinstellen und dann meldet mir WM nach RUN, dass das erstellen des ZIP Files nicht funktioniert.

Ich bin nun zurück auf 2000 und hab mal geschaut wie er den Befehl in einer Variablen zusammenbaut (DISPLAY CMD)
Ich erhalte:
"C:\Programme\WINZIP\winzip32.exe -a ""C:\Temp\Bildarchiv\1.zip""  ""C:\Temp\Bildarchiv\\Umbau.020.jpg"" ""C:\Temp\Bildarchiv\\Umbau.021.jpg""".

Mit RUN CMD erstellt er auch brav die ZIP.
Gebe ich das nun in eine Dos Shell ein, dann meint er die Syntax ist falsch.

So nun meine Frage:
Habe ich die Möglichkeit "nachzuschauen" was er wirklich mit RUN an die DOS Shell übergibt? Dann kann ich das maskieren von C:\Program Files besser debuggen.

A. Stulz

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zu einem aehnlich gelagerten Problem siehe http://www.clausbrod.de/Blog/BlogOnSoftware20060318 . Dort wird erklaert, welchen Weg eine Kommandozeile in OSDM nimmt, bis sie bei der DOS-Shell ankommt, welche Probleme es dabei geben kann, und wie man die Anfuehrungszeichen richtig setzt. Man kann daraus vermutlich auch fuer OSM/WM lernen.

Solche Probleme kann man aber recht einfach debuggen. Beispielsweise koenntest Du ein Miniprograemmchen schreiben, das "winzip33.exe" heisst und nur seine Argumente mitprotokolliert oder ausgibt, wenn Du es aufrufst.

Oder aber Du nimmst Dir den Process Explorer von http://www.sysinternals.com und schaust Dir die Kommandozeile des Prozesses winzip32.exe an, solange er noch laeuft.

Die Kommandozeile innerhalb von WM unterscheidet sich in der Tat von der, die letztlich bei der DOS-Shell ankommt; dass die Original-"Kommandozeile" aus WM in der DOS-Shell nicht tut, ist daher ueberhaupt nicht ueberraschend, zumal sich die Quotierungsregeln auch noch zwischen den verschiedenen Ebenen (WM-Makros, interner C-Code, DOS-Shell) unterscheiden.

Claus

------------------
OneSpace Designer Modeling FAQ: http://www.clausbrod.de/Osdm/

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Claus,
danke für die schnelle Antwort,
ich gehe nun nochmal genauer ein, da die Tipps mir nicht so richtig helfen:
Ein Miniprogramm würde mir nur den hinteren Teil anzeigen und Process Explorer ist auch schwierig, da kein Winzip startet.

Ich habe eine globale Variable:
LET Awmc_db_val_pack_cmd            'C:\Programme\WINZIP\winzip32.exe -a'
Der RUN Befehl wird zusammengesetzt:
LET Cmd (Awmc_db_val_pack_cmd+' "'+Awm_val_tmpdir+'\'+Import_file+'" ')
--> ""C:\Programme\WINZIP\winzip32.exe -a" "c:\Temp\Bildarchiv""
Dann wird über die Auswahl der Dateien mit einer WHILE Schleife der Rest des Strings generiert.

Über ein DISPLAY erhalte ich:
"C:\Programme\WINZIP\winzip32.exe -a ""C:\Temp\DBA24946.zip""  ""C:\Temp\Bildarchiv\Umbau.020.jpg"" ""C:\Temp\Bildarchiv\Umbau.021.jpg"""

Um nun das Makro auf XP mit C:\Program Files zum laufen zu bekommen habe ich nun experimentiert:
Zunächst habe ich die Variable geändert:

LET Awmc_db_val_pack_cmd            ('"'+(READ_ENV 'ProgramFiles') + '\WINZIP\winzip32.exe" -a')
Hier soll auch mal sauber mit den Systemvariablen gearbeitet werden.
An dieser Stelle scheitert dann das Makro.
Mit Display erhalte ich die Ausgabe:
"""C:\Program Files\WINZIP\winzip32.exe"" -a ""C:\Temp\DBA64034.zip""  ""C:\Temp\Bildarchiv\Umbau.020.jpg"" ""C:\Temp\Bildarchiv\Umbau.021.jpg"""

Nach weiteren experimentieren habe ich eine Konstellation gefunden
bei dem es zunächst läuft:
LET Cmd (Awmc_db_val_pack_cmd+' '+Awm_val_tmpdir+'\'+Import_file+' ').
Ich habe also die " aus dem hinteren Teil des Strings entfernt.
Mit DISPLAY erhalte ich """C:\Program Files\WINZIP\winzip32.exe"" -a C:\Temp\DBA24717.zip  C:\Temp\Bildarchiv\Umbau.020.jpg C:\Temp\Bildarchiv\Umbau.021.jpg"

So nun kann ich an dieser Stelle aufhören, was aber dann bedeutet, dass weder das ImportDIR oder der Dateiname ein Leerzeichen enthält. Das ist natürlich nicht erwünscht, da es bisher mit Leerzeichen funktioniert.

Ich verstehe nun nicht mehr, was den Fehler auslöst und was DOS
meldet.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mir sieht das wirklich wie eine fast 100%ige Entsprechung der Situation aus, wie ich sie in meinem Blog beschrieben habe. Sie tritt unabhaengig vom Betriebssystem und der Sprache auf - entscheidend ist nur, wie man seine Dateien benennt und wo man seine Programme ablegt und ob in diesen Pfaden zufaellig Leerzeichen sind. Auch die deutsche Version kann betroffen sein - dort heisst das Programmverzeichnis normalerweise zwar "C:\Programme", aber Anwenderdaten liegen unter "C:\Dokumente und Einstellungen"...

Ich habe eine aehnliche Situation nun gerade in OSDD nachzustellen versucht; einen WM hatte ich gerade nicht greifbar, und die Makrosprache ist ja recht aehnlich.

Ausserdem habe ich mir erlaubt, die Situation etwas zu vereinfachen, um das Problem klarer herauszuarbeiten. Dazu habe ich ein Verzeichnis "C:\temp\foo bar" angelegt, dort eine Kopie von write.exe aus dem Windows-Systemverzeichnis angelegt, ausserdem eine Textdatei mit Leerzeichen im Namen ("foo bar.txt").

Der folgende Makrocode funktioniert auch in so einer Situation:

Code:

---

LET Cmd '"C:\temp\foo bar\write.exe"'
LET File '"C:\temp\foo bar\foo bar.txt"'
LET Fullcmd (Cmd + " " + File)
LET Fullcmd ('"' + Fullcmd + '"')
RUN Fullcmd

---

Entscheidend ist die vorletzte Zeile. Laesst man sie weg, geht gar nichts. Warum diese Zeile gebraucht wird und dass das so ziemlich in allen Applikationen noetig ist, die ein externes Programm starten koennen, habe ich in meinem Blog erklaert.

Ich hoffe, dass das nun auch in Deinem konkreten Problem weiterhilft. In jedem Fall wuerde ich Dir empfehlen, erst einmal einen einfacheren Testfall zu bauen.

Claus

------------------
OneSpace Designer Modeling FAQ: http://www.clausbrod.de/Osdm/

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Claus,
das hat mir nun keine Ruhe gelassen, ich habe eben noch den WM über DSL und VPN zuhause gestartet (Wartezeit erhöhte die Spannung) und habe grob getestet...
Die entscheidende vorletzte Zeile (Fullcmd) scheint nun wirklich das Problem zu lösen!
Nun kann ich bestimmt ruhig schlafen und die Tests morgen wiederholen und hoffentlich als Änderung einarbeiten.

Ein dickes Dankeschön an dich!!!
Beim Surfen in den Foren findet man ja oft deine Antworten, die den "Leidenden" fundiert helfen. Auch ich habe still und leise gehofft, dass du antwortest :-)
Weiter so kann ich da nur sagen!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Und, hat's auch in der rauhen echten Arbeitswelt geklappt? 

Claus

------------------
OneSpace Designer Modeling FAQ: http://www.clausbrod.de/Osdm/

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Claus,
bin echt begeistert, alle Tests soweit OK, habe es produktiv geschalten. Mein Kollege hat sich der Sache auch gleich angenommen, da er das für das starten von Excel braucht und auch schon am verzweifeln war :-)

Herzlichen Dank
Andreas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP