Inoffizielles deutsches Xbase-Forum

brandelh hat geschrieben:DOS Programm kann mit den langen Namen (und teilweise mit Umlauten) nichts anfangen !

Das war es

Verzeichnisname zu lang + Datei die aufgerufen werden soll zu lang! Ich Depp
Das hat mich jetzt - ich sag's Euch lieber nicht - Stunden gekostet.

Es funktioniert jetzt sowohl der Aufruf des externen Programms direkt aus der Clipper Applikation als auch der Aufruf einer Batch-Datei.
Allerdings habe ich mir von dem Aufruf der Batch-Datei etwas mehr versprochen.
Ich wollte gerne die Clipper Anwendung - bis zum verlassen des aufgerufenen Programms "blocken".
Das funktioniert leider nicht. Ich lasse mich natürlich gerne vom Gegenteil überzeugen

Bei meinen Beispielen blockt es, was machst du anders ?

Du schreibst Clipper 5.3 GUI Programm, mit 5.3 habe ich nie gearbeitet, GUI dürfte eher ein "Text-Fenster System mit Mausbedienung" sein,
aber man kann natürlich nicht ausschließen, dass die das geschafft haben den RUN asyncron laufen zu lassen ...

compliere mein Beispiel mal mit Clipper 5.3 und schau was geschieht.

Guten Morgen,

doch Hubert, nach dem ich die Pfade und die Bezeichnung des Xbase++ Programms angepasst habe (hatten beide zu viele Zeichen), bekomme ich es dann hin eine Batch-Datei zu starten, die dann das Xbase++ Programm aufruft (Dein Code in meiner Applikation!). Mit dem Unterschied, dass wenn es aus der GUI Anwendung aufgerufen wird, ich es sichtbares Command-Fenster bekomme (i.d. quasi die Ausführung der Batch läuft) und dann eben mein Xbase++ Programm. Schließe ich das Xbase++ Programm, so wird auch das Command-Fenster geschlossen (das Command-Fenster kommt nicht von dem Xbase++ Programm, da es hier durch die AppSys() verhindert wird). Das Ausführen der Batch-Datei blockiert aber nicht die Clipper Anwendung, was ich mir gewünscht hätte.

Jetzt bastle ich schon an einem anderen Konstrukt.
Rufe wohl dann direkt aus der Clipper Anwendung mein Xbase++ Programm, Parameter übergebe ich wohl per Datei. Alles andere, z.B. Reagieren auf Ändern der Position in aufrufenden Clipper Anwendung, werde ich im Xbase++ Programm (Threads) abfangen.

Ich habe anfangs gedacht, dass ich die Clipper Anwendung dazu zwingen kann auf das Beenden des aufgerufenen Xbase++ Programms zu warten. Scheint aber mit meinen Clipper Kenntnissen nicht zu gelingen.

Hallo Magic,

hast du mein Beispiel oben mit Clipper 5.3 compiliert und probiert ?

Mit 5.2e macht es genau das was ich beschrieben habe und du möchtest.
Wenn genau dieses Beispiel mit 5.3 sich verhält wie dein Programm, muss Clipper 5.3 einen neuen Prozess starten, ob man das abschalten kann weiß ich nicht.
Wenn es sich aber wie gewünscht verhält, dann muss in deinem Clipper Programm oder in einer CH Datei eine Einstellung sein, die das Verhalten ändert.
Diese Einstellung könnte man dann ändern, wenn man weiß wie.

Ich kann dir aber nicht wirklich weiterhelfen, wir haben nie mit 5.3 gearbeitet.

Hallo Hubert,

nun habe ich exakt Deinen Code kompiliert.
Es funktioniert wir von Dir beschrieben.

Aber,
sobald das aufrufende Programm keine Console Applikation ist ( ), funktioniert es nicht mehr so. Dann wird wohl ein Separater Prozess gestartet und das aufrufende Programm läuft normal weiter.

Ich habe hier XP SP3, was hast du ?

Ich auch.

Wie gesagt, sobald ich das aus der GUI aufrufe ist das verhalten bei: undgleich.

Die EXE wird richtig ausgeführt (ohne sichtbare Command-Fenster - nur über die Batch flackert es kurz auf, das ist mir aber egal),
aber die aufrufende Applikation wartet nicht bis sie beendet wird. Ich kann also in beiden Applikationen dann parallel arbeiten.

Ich überlege aber gerade, ob es nicht möglich wäre, die Clipper Applikation irgendwie selbst "schlafen" zu legen, bis - meinetwegen - irgendwo ein Eintrag generiert wird
Mir ist die Funktionsweise von Clipper nicht bekannt, so weit ich es verstanden habe gibt es da keine Events wie sie in XBase++ existieren( )

Dann wird wohl ein Separater Prozess gestartet und das aufrufende Programm läuft normal weiter.

Alles andere wäre auch Unsinn.

Das sehen I-Pad-User sicherlich anders

Viele Grüße,
Martin

Martin Altmann hat geschrieben:I-Pad-User

Was für User
Kenne ich nicht, ... will ich auch nicht kennen
Ich stehe zu meinem Lumia. Da hält der Akku zumindest einen Tag lang.
Ok, einen halben wenn man ehrlich ist. Genauer gesagt von morgens bis abends.
Ich könnt Ko....

Tom hat geschrieben:

Dann wird wohl ein Separater Prozess gestartet und das aufrufende Programm läuft normal weiter.

Alles andere wäre auch Unsinn.

Bei meinem Beispiel mit Clipper 5.2e und XP Pro (Windows 7 habe ich nicht probiert) hält das Clipperprogramm bis
die Batch beendet wird. Und das ist in diesem Fall kein Unsinn, sondern wäre für Magic wichtig
@ Magic, mein Xbase++ Programm ist übrigens ein GUI Programm - wie man an der MSGBOX sieht !

Wer neue Prozesse will, schreibt normalerweise START davor, aber warum es bei Magic anders läuft weiß ich nicht.

Magic hat geschrieben:Ich überlege aber gerade, ob es nicht möglich wäre, die Clipper Applikation irgendwie selbst "schlafen" zu legen, bis - meinetwegen - irgendwo ein Eintrag generiert wird

Das habe ich jetzt durch eine simple DO WHILE .T. Schliefe realisiert, in der die Existenz einer Datei mit File() geprüft wird.
Ist die Datei vorhanden, so verlasse ich die Schleife mit EXIT.
Gibt es in Clipper eine Möglichkeit die Schleife mit Speep() etwas zu "verlangsamen" - es muss ja nicht permanent geprüft werden.
Und kann ich Mausereignisse für die Zeit verbieten / ignorieren?

für solche "Wartezustände" nimmt man inkey(0.1) / 0,1 Sekunde oder etwas höhere Werte.

brandelh hat geschrieben:Wer neue Prozesse will, schreibt normalerweise START davor, aber warum es bei Magic anders läuft weiß ich nicht.

Damit wir jetzt nicht an einander vorbei reden.
Dein Beispielcode, läuft bei mir genau so wie bei Dir.
Aber sobald ich in der .BAT eine andere XBase++ Anwendung aufrufe (also eine die nicht nur eine Message-Box ausgibt ~mit Eventloop, etc.) dann wartet die erste Applikation nicht auf das beenden der aufgerufenen.

Bingo, das war mein Fehler !

Die MSGBOX stoppt das Programm, das hatte ich jetzt übersehen.
Die Sperre mit einer Datei geht normalerweise gut, solange man keine Windows Server 2008 hat.
Diese beantworten nicht jede Anfrage nach einer Datei richtig um die Netzlast zu senken (darüber wurde hier schon lange diskutiert).
Wenn du aber eine DBFNTX-DBF mit Standardeinstellungen nimmst und einen Satz oder die Datei (Flock() ist schneller, aber nur im Einzelplatz möglich) sperrst, dann sollte Clipper beim Versuch diese zu sperren einen Fehler melden. Solange also dort flock() fehlschlägt wartet das Clipperprogramm auf deine Xbase++ Anwendung.

Magic hat geschrieben:Ich habe es mit SWPRUNCMD versucht. Keine Chance, ich meine auch irgendwo gelesen zu haben dass dieser Befehl nicht mehr unterstütz wird.

das gilt für 64bit OS()

versuch mal das ( mit "warten" )