Externes Prog. aufrufen & auf Beendigung warten [ERLEDIGT]
Moderator: Moderatoren
Externes Prog. aufrufen & auf Beendigung warten [ERLEDIGT]
Hi,
ich versuche aus einer Clipper 5.3 Applikation ein externes Programm aufzurufen.
Ich habe es mit SWPRUNCMD versucht. Keine Chance, ich meine auch irgendwo gelesen zu haben dass dieser Befehl nicht mehr unterstütz wird.
Bei Verwendung von RUN sagt mit der Blinker: „nicht aufgelöstes External“.
Hat vielleicht jem. eine Idee Muss ich noch etwas anders linken
Ich bin kein Clipper Programmierer. Kleine Änderungen / Erweiterungen, Kompilieren und Linken bekomme ich aber hin.
ich versuche aus einer Clipper 5.3 Applikation ein externes Programm aufzurufen.
Ich habe es mit SWPRUNCMD versucht. Keine Chance, ich meine auch irgendwo gelesen zu haben dass dieser Befehl nicht mehr unterstütz wird.
Bei Verwendung von RUN sagt mit der Blinker: „nicht aufgelöstes External“.
Hat vielleicht jem. eine Idee Muss ich noch etwas anders linken
Ich bin kein Clipper Programmierer. Kleine Änderungen / Erweiterungen, Kompilieren und Linken bekomme ich aber hin.
Zuletzt geändert von Magic am Fr, 04. Mai 2012 15:09, insgesamt 1-mal geändert.
Gruß,
Magic
Magic
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Es wäre "RUN". Syntax:
RUN <Name der EXE> <Parameter>
also:
RUN <Name der EXE> <Parameter>
also:
Code: Alles auswählen
RUN c:\test\test.exe blubb
Herzlich,
Tom
Tom
Re: Externes Programm aufrufen
Hallo Tom,
Danke. So habe ich es gemacht. Leider bekam ich diese Meldung beim linken.
Gerade habe ich die Ursache dafür gefunden.
Ich habe den Befehl direkt im Codeblock angegeben. Das hat ihm nicht geschmeckt.
Jetzt rufe ich erst eine Funktion auf und darin dann das RUN - es klappt.
Danke. So habe ich es gemacht. Leider bekam ich diese Meldung beim linken.
Gerade habe ich die Ursache dafür gefunden.
Ich habe den Befehl direkt im Codeblock angegeben. Das hat ihm nicht geschmeckt.
Jetzt rufe ich erst eine Funktion auf und darin dann das RUN - es klappt.
Gruß,
Magic
Magic
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
genau, in Codeblocks darf man nur Funktionen aufrufen, Prozeduren und Befehle funktionieren nicht.
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
... jetzt suche ich nur noch die richtigen Einstellungen / Parameter.
Ich will aus der Clipper Anwendung eine Xbase++ Anwendung aufrufen (kleines Progrämmchen).
Einen (wenn es geht auch mehrere) Parameter übergeben.
Und das Ausführen in einem bestimmten Verzeichnis erzwingen (wie "ausführen in" bei Verknüpfungen).
Ich will aus der Clipper Anwendung eine Xbase++ Anwendung aufrufen (kleines Progrämmchen).
Einen (wenn es geht auch mehrere) Parameter übergeben.
Und das Ausführen in einem bestimmten Verzeichnis erzwingen (wie "ausführen in" bei Verknüpfungen).
Gruß,
Magic
Magic
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Hubert: Tippfehler? Natürlich kann man Prozeduren in Codeblöcken aufrufen; Prozeduren sind letztlich Funktionen, nur ohne Rückgabewert. Kommandos funktionieren nicht.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Xbase++ bildet eine PROCEDUR als FUNKTION mit Rückgabewert NIL (also nichts) ab.Tom hat geschrieben:Hubert: Tippfehler? Natürlich kann man Prozeduren in Codeblöcken aufrufen;
Prozeduren sind letztlich Funktionen, nur ohne Rückgabewert. Kommandos funktionieren nicht.
Wenn ich aber eine solche Prozedur wie üblich im codeblock angebe, also ohne Klammern, dann wird das als Variable gelesen ...
Code: Alles auswählen
procedure main
local nN1, nN2
nN1 := 0
nN2 := 0.000000
? nN1
? nN2
? str(nN1), "Integer ?", IsInteger(nN1)
? str(nN2), "Integer ?", IsInteger(nN2)
nN1 *= 1
nN2 := int(nN2)
? str(nN1), "Integer ?", IsInteger(nN1)
? str(nN2), "Integer ?", IsInteger(nN2)
eval( {|| teste } ) ******************************************
wait
return
function IsInteger(nWert)
return ! ("." $ str(nWert))
procedure TESTE
? "Test OK"
return
Code: Alles auswählen
eldung:
------------------------------------------------------------------------------
FEHLERPROTOKOLL von "D:\TEST\TestBigFiles\test1.exe" Datum: 02.05.2012 13:03:41
Xbase++ Version : Xbase++ (R) Version 1.90.355
Betriebssystem : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args :
-> NIL
oError:canDefault : N
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Unbekannte Variable
oError:filename :
oError:genCode : 22
oError:operation : teste
oError:osCode : 0
oError:severity : 2
oError:subCode : 2000
oError:subSystem : BASE
oError:thread : 1
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von (B)MAIN(14)
Aufgerufen von MAIN(14)
Ob der Clipper das auch so macht - wir sind hier ja im Clipper Unterforum - weiß ich gar nicht mehr ...
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Auch Prozeduraufrufe können (Aufruf-)Parameter enthalten, und Clipper unterstützt natürlich auch diese Syntax (MyProcedure(<p1>,<p2>)), sowie den ohne (MyProcedure()). Ja, klar, in Codeblöcken sollte dies - zur Unterscheidung von Variablen - mit Klammern erfolgen. Logo. Auch das alte "DO MyProcedure" geht da nicht.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
ich habe meine alte Clipper 5.2e Installation entstaubt und das Programm dort probiert und es verhält sich gleich.brandelh hat geschrieben:Ob der Clipper das auch so macht - wir sind hier ja im Clipper Unterforum - weiß ich gar nicht mehr ...
Somit hat auch Clipper 5.2e wenn möglich LONG benutzt und PROCEDUREN mit Function return NIL umgesetzt.
Aber TOM hat natürlich Recht, eine Prozedur mit Klammerpaar funktioniert, somit ist nur die Aussage "COMMANDOS darf man nicht in Codeblöcken verwenden" richtig.
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
Bin immer noch am basteln der Batchdatei …
Das Vorgehen ist klar.
Aus der Clipper Anwendung eine Batch mit RUN aufrufen.
Aus der Batch heraus
Clipper Anwendung -> Batch -> Xbase++ Programm, nach Schließung des Programms wieder zurück zu der Clipper Anwendung.
Solange das Xbase++ Programm ausgeführt wird, soll die Clipper Anwendung warten. Also quasi ein Verhalten wie beim ausführen von Modal Fenstern.
Meine Batch sieht so aus
Führe ich nun die Batch Datei aus, so sehe ich ein Command Fenster, kurz darauf startet das Xbase++ Programm. Schließe ich nun das Xbase++ Programm wird auch automatisch das Command Fenster geschlossen.
Frage: Kann ich die Sichtbarkeit des Command Fensters verhindern? So dass ich nur das Xbase++ Programm sehen?
Starte ich die Batch Datei aus meiner Clipper Anwendung, so passiert gar nichts. Er läuft über die RUN Anweisung drüber (ich gebe mir vor und nach dem Aufruf Message Boxen aus) und es passiert nichts. Also zumindest nichts was ich sehen könnte. Die Anwendung lässt sich normal bedienen, wartet also auch auf nichts.
Das Vorgehen ist klar.
Aus der Clipper Anwendung eine Batch mit RUN aufrufen.
Aus der Batch heraus
Clipper Anwendung -> Batch -> Xbase++ Programm, nach Schließung des Programms wieder zurück zu der Clipper Anwendung.
Solange das Xbase++ Programm ausgeführt wird, soll die Clipper Anwendung warten. Also quasi ein Verhalten wie beim ausführen von Modal Fenstern.
Meine Batch sieht so aus
Code: Alles auswählen
@echo off
START /D<mein Ausführen in Verzeichnis> /WAIT <mein Xbase++ Programm>
Frage: Kann ich die Sichtbarkeit des Command Fensters verhindern? So dass ich nur das Xbase++ Programm sehen?
Starte ich die Batch Datei aus meiner Clipper Anwendung, so passiert gar nichts. Er läuft über die RUN Anweisung drüber (ich gebe mir vor und nach dem Aufruf Message Boxen aus) und es passiert nichts. Also zumindest nichts was ich sehen könnte. Die Anwendung lässt sich normal bedienen, wartet also auch auf nichts.
Gruß,
Magic
Magic
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
ein 16 bit DOS Clipper Programm das ein 32 bit Xbase++ mit RUN steuern will, das halte ich für sehr problematisch, falls es überhaupt geht ?
DOS Anwendungen blockieren BAT Dateien, CONSOLE Anwendungen blockieren CMD Dateien, GUI Anwendungen sollten die CMD nicht blockieren.
Wenn überhaupt, solltest du die Steuerung nicht mit RUN machen, sondern z.B. beide Programme laufen lassen und über eine gesharte DBF syncronisieren.
Früher habe ich auch die Rückgabewerte der Clipperprogramme mit if errorlevel ... zur Steuerung genutzt, aber CMD / BAT gemischt ?
DOS Anwendungen blockieren BAT Dateien, CONSOLE Anwendungen blockieren CMD Dateien, GUI Anwendungen sollten die CMD nicht blockieren.
Wenn überhaupt, solltest du die Steuerung nicht mit RUN machen, sondern z.B. beide Programme laufen lassen und über eine gesharte DBF syncronisieren.
Früher habe ich auch die Rückgabewerte der Clipperprogramme mit if errorlevel ... zur Steuerung genutzt, aber CMD / BAT gemischt ?
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
Ich würde auch liebend gerne auf dieses Konstrukt verzichten, aber etwas Besseres fällt mir momentan nicht ein.
Ich will das nicht mit Gewalt im Clipper programmieren, da hierfür meine Clipper Kenntnisse nicht ausreichen – ohne alles mir irgendwie zusammen kopieren zu müssen.
Jede andere Idee ist willkommen
Ich will das nicht mit Gewalt im Clipper programmieren, da hierfür meine Clipper Kenntnisse nicht ausreichen – ohne alles mir irgendwie zusammen kopieren zu müssen.
Jede andere Idee ist willkommen
Gruß,
Magic
Magic
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Ich habe es mal eben unter XP Professional (32 Bit) probiert. Eine *.BAT Datei kann alle 3 EXE-Arten starten und jede Zeile wird blockiert bis das Programm fertig ist.
Wenn ein Programm beendet wird, kann man einen sogenannten Errorlevel zurückgeben:
QUIT [<nErrorLevel>] oder Return von Main mit Parameter => siehe in der Hilfe zu QUIT.
Die Frage ist was du machen willst, Xbase++ Programme sind von der Syntax ähnlich wie Clipper
Wenn ein Programm beendet wird, kann man einen sogenannten Errorlevel zurückgeben:
QUIT [<nErrorLevel>] oder Return von Main mit Parameter => siehe in der Hilfe zu QUIT.
Die Frage ist was du machen willst, Xbase++ Programme sind von der Syntax ähnlich wie Clipper
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
Welche Arten meinst Du?brandelh hat geschrieben:alle 3 EXE-Arten
Ich gehe jetzt mal davon aus, dass Du direkt eine Batch ausgeführt hast.brandelh hat geschrieben:Eine *.BAT Datei kann alle 3 EXE-Arten starten
Das klappt so bei mir auch. Nur lässt sich das ganze nicht aus der Clipper Anwendung starten - ich bekomme es nicht hin.
Gruß,
Magic
Magic
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
du verwendest oben die START Anweisung, diese verhindert einen Wartezustand.
Mit den 3 EXE Arten meinte ich DOS 16 bit, Console 32 Bit und GUI 32 bit.
die BAT Datei sollte so aussehen:
ob diese BAT über RUN eine Xbase++ starten kann weiß ich aber nicht, das habe ich nie probiert (16 BIT Prozess startet 32 BIT Prozess )
Daher meine Frage, was das neu Programm eigentlich machen soll.
Wenn es z.B. Aufgaben abarbeiten soll, könnte man es anders syncronisieren ...
Mit den 3 EXE Arten meinte ich DOS 16 bit, Console 32 Bit und GUI 32 bit.
die BAT Datei sollte so aussehen:
Code: Alles auswählen
@echo off
MeinXbaseProgramm.exe => so blockiert dieses
REM für Fehlersuche eine Meldung und ein Wartezustand
echo Ende
pause
Daher meine Frage, was das neu Programm eigentlich machen soll.
Wenn es z.B. Aufgaben abarbeiten soll, könnte man es anders syncronisieren ...
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
Ich würde nach all meinen Tests wohl auf ein Nein wetten. Da passiert einfach nichts.Magic hat geschrieben:ob diese BAT über RUN eine Xbase++ starten kann weiß ich aber nicht, das habe ich nie probiert (16 BIT Prozess startet 32 BIT Prozess )
Der Benutzer Bearbeitet in der Clipper Anwendung einen Auftrag. Ruft dann ein Xbase++ Programm auf in dem er "ein paar Daten" pflegt (ich muss aber hier ein paar Validierungen realisieren), schließt das Fenster und bearbeitet den Auftrag weiter.brandelh hat geschrieben:Daher meine Frage, was das neu Programm eigentlich machen soll.
Eigentlich ruft er nur ein modales Fenster auf, dass es dann in XBase++ realisiert worden ist, wird er zwar an der Optik erkennen können, aber für den Anwender soll es so sein als wäre es ein "normales" Fenster seiner bisherigen Clipper Anwendung.
Die Synchronisation ist hier gar nicht so das Problem (denke ich). Ich muss auch keine Werte zurück geben, nur darauf warten dass das "neue" Fenster geschlossen wird.
Aber so wie es scheint, bekomme ich es überhaupt nicht hin, eine 32Bit Anwendung aus Clipper zu starten.
Gruß,
Magic
Magic
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Selbstverständlich kann eine Batch-Datei, die über Kommandozeilenprozessor gestartet wird, auch ein Xbase++-Programm aufrufen. Allerdings wird das scheitern, wenn das fragliche Xbase-Programm oder seine Laufzeitbibliotheken nicht sichtbar sind. Dafür sollte man einfach mal die Situation manuell nachstellen, also im Command-Prompt ins Arbeitsverzeichnis des Clipper-Programmes wechseln und dort die Batchdatei ausführen. Außerdem ist zu beachten, dass je nach Betriebssystem andere Environment-Variablen gesetzt sind (PATH usw.) - oder überhaupt keine. Ggf. muss die Batchdatei das Verzeichnis wechseln ("CD \WomeineXbaseAppliegt"). Das hat übrigens keine Auswirkungen darauf, welche Daten die weiterlaufende Clipper-App sieht - ihr Verzeichnis wird nicht gewechselt.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Gibt es die Xbase++ Anwendung schon ?
Wenn nicht, ist ein modales Fenster in Clipper mit @ say get der einfachste Weg.
Wenn nicht, ist ein modales Fenster in Clipper mit @ say get der einfachste Weg.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
und bei der Xbase++ EXE müssen alle Runtime dll liegen.Tom hat geschrieben:Ggf. muss die Batchdatei das Verzeichnis wechseln ("CD \WomeineXbaseAppliegt").
PS: mit TITLE kann man seit XP in der BATCH Datei die Bezeichnung des Fensters ändern,
mit API Funktionen sollte man dieses dann in Xbase++ auch verstecken können.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Hi,
das mit dem TITLE in der BAT geht zwar nicht, ist aber auch gar nicht nötig.
Wie ich eben probiert habe geht das alles recht einfach, das "scharze Fenster" kam NICHT von der BAT, sondern von Xbase++ GUI und unveränderter appsys().
In der angehängten ZIP gibt es ein ProgCLP.PRG, das muss mit Clipper (getestet mit 5.2e) kompiliert werden und startet den Test.
Die Xbase++ Anwendung (zeigt nur eine msgbox) wird mit PBUILD kompiliert.
Bei mir startet das Clipperprogramm, ENTER (oder andere Taste) startet ProgW32.EXE ...
im DOS Fenster kommt "Anwendung nicht gefunden" => das ist TITLE (geht nur in CMD Boxen)
Dann ist auch sofort schon die MSGBOX() da.
Nach Ende dieser erscheint die Endemeldung im DOS Programm.
So wolltest du es doch haben oder ?
Bei mir brauchte ich die DLLs nicht ins EXE Verzeichnis kopieren, die normalen Win32 Pfade werden somit verwendet ...
Hier der Quellcode zum Ansehen ... zunächst das Clipperprogramm
wenn man über den Explorer startet sollte man ein inkey(10) nach @ 5,1 ... setzen, damit man es besser sieht.
nun das sehr einfache Xbase++ Programm, die Projektdatei hat GUI=YES
Clipper ruft diese BAT Datei auf, BAT kann kein title ... aber das ist egal.
das mit dem TITLE in der BAT geht zwar nicht, ist aber auch gar nicht nötig.
Wie ich eben probiert habe geht das alles recht einfach, das "scharze Fenster" kam NICHT von der BAT, sondern von Xbase++ GUI und unveränderter appsys().
In der angehängten ZIP gibt es ein ProgCLP.PRG, das muss mit Clipper (getestet mit 5.2e) kompiliert werden und startet den Test.
Die Xbase++ Anwendung (zeigt nur eine msgbox) wird mit PBUILD kompiliert.
Bei mir startet das Clipperprogramm, ENTER (oder andere Taste) startet ProgW32.EXE ...
im DOS Fenster kommt "Anwendung nicht gefunden" => das ist TITLE (geht nur in CMD Boxen)
Dann ist auch sofort schon die MSGBOX() da.
Nach Ende dieser erscheint die Endemeldung im DOS Programm.
So wolltest du es doch haben oder ?
Bei mir brauchte ich die DLLs nicht ins EXE Verzeichnis kopieren, die normalen Win32 Pfade werden somit verwendet ...
Hier der Quellcode zum Ansehen ... zunächst das Clipperprogramm
Code: Alles auswählen
cls
@ 1,1 say "Ich bin das Clipperprogramm"
@ 3,1 say "ESC=Ende, ENTER startet Xbase++ Programm"
if inkey(0)=27
quit
else
@ 4,1 say "Starte test.bat"
run test.bat
@ 5,1 say "Nach text.bat"
endif
return
nun das sehr einfache Xbase++ Programm, die Projektdatei hat GUI=YES
Code: Alles auswählen
procedure appsys // kein crt fenster
return
procedure main
msgbox("ProgW32 zeigt diese Meldung","Info")
return
Code: Alles auswählen
@echo off
title Clipper startet Xbase++ Anwendung
ProgW32.exe
if errorlevel=1 goto fehler
goto ende
:fehler
echo *** Fehler ***
:ende
pause
- Dateianhänge
-
- cli2xb.zip
- (1.02 KiB) 409-mal heruntergeladen
Gruß
Hubert
Hubert
Re: Externes Programm aufrufen
Zuerst danke Hubert für Deine ausführliche Anleitung.
Die Hilfsbereitschaft ist ja „gigantisch“
Ich habe Dein Beispiel bei mir in der Anwendung nachgebaut und bekomme folgendes Ergebnis:
Aber zuerst die Ausgangssituation:
Ich starte eine Clipper Anwendung aus einem Verzeichnis CLIPPER im Netzwerk.
In einem anderem Verzeichnis XBASE (gleicher Server) liegt das zu startende Xbase++ Programm.
Das Xbase++ Programm lässt sich direkt starten. Bis hierher OK.
Nun erzeuge ich zwei Batch-Dateien. Eine lege ich in das CLIPPER Verzeichnis (hier raus wird die Clipper Anwendung gestartet), die andere in das XBASE Verzeichnis (hier liegt das zu startende Xbase++ Programm). Beide Batch-Dateien kann ich im Explorer per Doppelklick ausführen, beide liefern das richtige Ergebnis. Sie starten das Xbase++ Programm ordnungsgemäß. Bis hierher OK.
Jetzt starte ich ein Command Fenster und wechsle in das CLIPPER Verzeichnis. Hier rufe ich die Batch-Datei, die auch in diesem Verzeichnis liegt. Das Xbase++ Programm wird gestartet. Bis hierher OK.
Jetzt versuche ich (ich befinde mich im CLIPPER Verzeichnis) die Batch-Datei aus dem XBASE Verzeichnis zu starten. Bekommen die Fehlermeldung: „Der Befehl <MeinXBaseProgramm.EXE> ist entweder falsch geschrieben oder konnte nicht gefunden werden.“ Wechsle ich in das XBASE Verzeichnis lässt sich die Batch-Datei problemlos ausführen. Ich passe die Batch-Datei an, und ergänze den Aufruf meines Xbase++ Programms um den kompletten Pfad. Starte jetzt noch mal die Batch-Datei. Jetzt wird das Xbase++ Programm ausgeführt. OK.
Bis hier her – würde ich sagen – ist alles i.O. Also wenn ich es manuell ausführe.
Nun ergänze ich meine Clipper Anwendung um den Aufruf der Batch-Datei. Zur Testzwecken rufe ich beide Batch-Dateien (sie liegen ja in zwei unterschiedlichen Verzeichnissen) nacheinander mit RUN auf. Vor und nach dem Batch Aufruf gebe ich mir Message Boxen aus. Es passiert nichts. Die Message-Boxen werden ausgegeben, die Batch-Datei (oder der RUN Befehl) nicht ausgeführt. Nicht einmal eine Verzögerung.
Ich teste auf einem XP Rechner. Bei der Clipper Anwendung handelt es sich um ein 16Bit GUI Anwendung, kompiliert mit der Version 5.3.
Noch ein Test. Ich ändere den RUN Aufruf in der Clipper Anwendung und ergänze mit Klammern.
in
Ergebnis: Unter XP keine Auswirkungen. (Achtung: unter Win98 wird die zweite Batch-Datei jetzt ausgeführt.)
Ich habe jetzt keine Ahnung wo ich noch was anfassen muss und wieso Clipper über die RUN Anweisung drüber läuft ohne das etwas passiert.
Die Hilfsbereitschaft ist ja „gigantisch“
Ich habe Dein Beispiel bei mir in der Anwendung nachgebaut und bekomme folgendes Ergebnis:
Aber zuerst die Ausgangssituation:
Ich starte eine Clipper Anwendung aus einem Verzeichnis CLIPPER im Netzwerk.
In einem anderem Verzeichnis XBASE (gleicher Server) liegt das zu startende Xbase++ Programm.
Das Xbase++ Programm lässt sich direkt starten. Bis hierher OK.
Nun erzeuge ich zwei Batch-Dateien. Eine lege ich in das CLIPPER Verzeichnis (hier raus wird die Clipper Anwendung gestartet), die andere in das XBASE Verzeichnis (hier liegt das zu startende Xbase++ Programm). Beide Batch-Dateien kann ich im Explorer per Doppelklick ausführen, beide liefern das richtige Ergebnis. Sie starten das Xbase++ Programm ordnungsgemäß. Bis hierher OK.
Jetzt starte ich ein Command Fenster und wechsle in das CLIPPER Verzeichnis. Hier rufe ich die Batch-Datei, die auch in diesem Verzeichnis liegt. Das Xbase++ Programm wird gestartet. Bis hierher OK.
Jetzt versuche ich (ich befinde mich im CLIPPER Verzeichnis) die Batch-Datei aus dem XBASE Verzeichnis zu starten. Bekommen die Fehlermeldung: „Der Befehl <MeinXBaseProgramm.EXE> ist entweder falsch geschrieben oder konnte nicht gefunden werden.“ Wechsle ich in das XBASE Verzeichnis lässt sich die Batch-Datei problemlos ausführen. Ich passe die Batch-Datei an, und ergänze den Aufruf meines Xbase++ Programms um den kompletten Pfad. Starte jetzt noch mal die Batch-Datei. Jetzt wird das Xbase++ Programm ausgeführt. OK.
Bis hier her – würde ich sagen – ist alles i.O. Also wenn ich es manuell ausführe.
Nun ergänze ich meine Clipper Anwendung um den Aufruf der Batch-Datei. Zur Testzwecken rufe ich beide Batch-Dateien (sie liegen ja in zwei unterschiedlichen Verzeichnissen) nacheinander mit RUN auf. Vor und nach dem Batch Aufruf gebe ich mir Message Boxen aus. Es passiert nichts. Die Message-Boxen werden ausgegeben, die Batch-Datei (oder der RUN Befehl) nicht ausgeführt. Nicht einmal eine Verzögerung.
Ich teste auf einem XP Rechner. Bei der Clipper Anwendung handelt es sich um ein 16Bit GUI Anwendung, kompiliert mit der Version 5.3.
Noch ein Test. Ich ändere den RUN Aufruf in der Clipper Anwendung und ergänze mit Klammern.
Code: Alles auswählen
cBatch := „Meine.BAT“
RUN cBatch
cBatch := „Laufwerk:/Verzeichnis/CLIPPER/Meine.BAT“
RUN cBatch
Code: Alles auswählen
cBatch := „Meine.BAT“
RUN ( cBatch )
cBatch := „Laufwerk:/Verzeichnis/CLIPPER/Meine.BAT“
RUN ( cBatch )
Ich habe jetzt keine Ahnung wo ich noch was anfassen muss und wieso Clipper über die RUN Anweisung drüber läuft ohne das etwas passiert.
Gruß,
Magic
Magic
Re: Externes Programm aufrufen
So,
nach weiteren Tests stelle ich folgendes fest:
Der Aufruf eines externen Programms (aus dem Konstrukt heraus wie ich es oben beschrieben haben) funktioniert nur, wenn ich ein Programm aufrufe, welches lokal installiert ist. Dies ist aber in meiner Umgebung nicht gegeben.
Dann funktioniert bei mir aber auch nur die RUN Anweisung, wenn das Programm in Klammern angegeben wird.
Jetzt muss ich mir doch noch etwas anderes überlegen
nach weiteren Tests stelle ich folgendes fest:
Der Aufruf eines externen Programms (aus dem Konstrukt heraus wie ich es oben beschrieben haben) funktioniert nur, wenn ich ein Programm aufrufe, welches lokal installiert ist. Dies ist aber in meiner Umgebung nicht gegeben.
Dann funktioniert bei mir aber auch nur die RUN Anweisung, wenn das Programm in Klammern angegeben wird.
Code: Alles auswählen
cProg := C:\TEST.EXE
RUN cProg // funktioniert nicht (kommt auch keine Fehlermeldung)
RUN ( cProg ) // das funktioniert, wenn die EXE Lokal verfügbar ist – also nicht im Netzwerk
Gruß,
Magic
Magic
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
"RUN" ist ein Kommando, das Texte als Parameter erwartet, wie beispielsweise auch USE:Dann funktioniert bei mir aber auch nur die RUN Anweisung, wenn das Programm in Klammern angegeben wird.
Code: Alles auswählen
USE kunden
Das hier geht nicht:
Code: Alles auswählen
cDatei := "kunden"
USE cDatei
Das hier geht:
Code: Alles auswählen
cDatei := "kunden"
USE (cDatei) // "cDatei" wird ausgewertet
Code: Alles auswählen
cDatei := "kunden"
USE &cDatei // "cDatei" wird per Makro ausgewertet
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Externes Programm aufrufen
Hallo Magic,
Tom hat ja schon erklärt warum man die () um die Variable mit dem Dateinamen braucht.
Aber es gibt noch mehr Fallen ...
1. Blanks in Pfad oder Dateinamen ... hier muss man die Namen mit " umschließen.
Beispiel:
Hier muss man die " um den Variableninhalt herum legen (wie auch bei einer BAT direkt):
3. Ich würde das Verzeichnis des Clipperprogrammes in der Batch nicht wechseln und statt dessen im Xbase++ Programm die Pfade regeln.
Dieses kennt immer das eigene EXE Verzeichnis ! Mit Parametern könntest du ein Arbeitsverzeichnis übergeben.
2. DOS Programm kann mit den langen Namen (und teilweise mit Umlauten) nichts anfangen !
Du kannst mit API-Funktionen den kurzen Namen (8.3) der langen Namen ermitteln oder aber selbst command in einer CMD-Box starten.
Ab dem Zeitpunkt siehst du dann viele Namen mit ~ und Ziffern.
Besonders benutzerfreundlich ist dann das Anzeigen in einer Listbox in er der Anwender raten darf was wohl die richtige ist
Am Besten ist es nur 8.3 Namen zu verwenden, dann sind sie in beiden Welten identisch.
Tom hat ja schon erklärt warum man die () um die Variable mit dem Dateinamen braucht.
Aber es gibt noch mehr Fallen ...
1. Blanks in Pfad oder Dateinamen ... hier muss man die Namen mit " umschließen.
Beispiel:
Code: Alles auswählen
cProg := "d:\Mein schönes Verzeichnis\Meine Exe.exe"
run (cProg) => run d:\Mein schönes Verzeichnis\Meine Exe.exe => Fehler "d:\Mein existiert nicht" !
Code: Alles auswählen
cProg := chr(34)+"d:\Mein schönes Verzeichnis\Meine Exe.exe"+chr(34) // chr(34) = " in Ansi und OEM
run (cProg) => run (["d:\Mein schönes Verzeichnis\Meine Exe.exe"]) // hier als Beispiel [] als Zeichenbegrenzer außen " im Text.
Dieses kennt immer das eigene EXE Verzeichnis ! Mit Parametern könntest du ein Arbeitsverzeichnis übergeben.
2. DOS Programm kann mit den langen Namen (und teilweise mit Umlauten) nichts anfangen !
Du kannst mit API-Funktionen den kurzen Namen (8.3) der langen Namen ermitteln oder aber selbst command in einer CMD-Box starten.
Ab dem Zeitpunkt siehst du dann viele Namen mit ~ und Ziffern.
Besonders benutzerfreundlich ist dann das Anzeigen in einer Listbox in er der Anwender raten darf was wohl die richtige ist
Am Besten ist es nur 8.3 Namen zu verwenden, dann sind sie in beiden Welten identisch.
Gruß
Hubert
Hubert