Hallo,

Problem: Xbase++ - Programm auf Terminalclient:

Bei der Benutzung der Clients auf einem speziellen Terminalserver mit 
Windows 2008 Server tritt völlig aus heiterem Himmel (bis heute Mittag 
ging es noch) folgendes Problem auf:
Alle Runshell() - Aufrufe mit "/C START ...." bringen den DOS-Fehler 87 
(invalid Parameter).
Alle anderen PCs und TCs funktionieren ordentlich. Auch ein Neustart des 
Servers hat nichts gebracht.
Hat jemand schon mal dieses Problem gehabt bzw. weiss jemand eine Lösung?

Mit freundlichen Grüßen
Steffen Schubert

Am 15.01.2015 15:57, schrieb Steffen Schubert:
> Hallo,
>
> Problem: Xbase++ - Programm auf Terminalclient:
>
> Bei der Benutzung der Clients auf einem speziellen Terminalserver mit
> Windows 2008 Server tritt völlig aus heiterem Himmel (bis heute Mittag
> ging es noch) folgendes Problem auf:
> Alle Runshell() - Aufrufe mit "/C START ...." bringen den DOS-Fehler 87
> (invalid Parameter).
> Alle anderen PCs und TCs funktionieren ordentlich. Auch ein Neustart des
> Servers hat nichts gebracht.
> Hat jemand schon mal dieses Problem gehabt bzw. weiss jemand eine Lösung?
>
> Mit freundlichen Grüßen
> Steffen Schubert

Servus Steffen,

ja, gib den kompletten Pfad des aufrufenden Programmes an, dann sollte 
es funktionieren.

Beste Grüße,

Werner

Ein 'Helfer', nicht uber RunShell, sondern uber ShellExecuteA, ist auch fur's
Dokumenten geeinigt und print, edit, etc.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx


//modes for run, 0 and 1 most used
#define SW_HIDE             0
#define SW_NORMAL           1
#define SW_SHOWMINIMIZED    2
#define SW_SHOWMAXIMIZED    3
#define SW_MAXIMIZE         3
#define SW_SHOWNOACTIVATE   4
#define SW_SHOW             5
#define SW_MINIMIZE         6
#define SW_SHOWMINNOACTIVE  7
#define SW_SHOWNA           8
#define SW_RESTORE          9
#define SW_SHOWDEFAULT      10

PROCEDURE ShellOpenFile( cFile, nMode )

       DllCall( "SHELL32.DLL"  , DLL_STDCALL, ;
          "ShellExecuteA", AppDesktop():GetHWND(), "open", cFile, ;
          NIL, CurDir(), nMode )

RETURN

Soll auch an Terminal Servers gut sein.

Hallo Jurac,

danke für den Tipp, aber Shellopenfile() geht nur für Prozesse, die 
asynchron gestartet werden. Wenn ich auf das Ergebnis eines Prozesses 
warten muss, kann ich nur Runshell() nehmen.

Grüße Steffen


Am 19.01.2015 um 13:57 schrieb "Matej Jurac":
> Ein 'Helfer', nicht uber RunShell, sondern uber ShellExecuteA, ist auch fur's
> Dokumenten geeinigt und print, edit, etc.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
>
>
> //modes for run, 0 and 1 most used
> #define SW_HIDE             0
> #define SW_NORMAL           1
> #define SW_SHOWMINIMIZED    2
> #define SW_SHOWMAXIMIZED    3
> #define SW_MAXIMIZE         3
> #define SW_SHOWNOACTIVATE   4
> #define SW_SHOW             5
> #define SW_MINIMIZE         6
> #define SW_SHOWMINNOACTIVE  7
> #define SW_SHOWNA           8
> #define SW_RESTORE          9
> #define SW_SHOWDEFAULT      10
>
> PROCEDURE ShellOpenFile( cFile, nMode )
>
>         DllCall( "SHELL32.DLL"  , DLL_STDCALL, ;
>            "ShellExecuteA", AppDesktop():GetHWND(), "open", cFile, ;
>            NIL, CurDir(), nMode )
>
> RETURN
>
> Soll auch an Terminal Servers gut sein.
>

Hallo Steffen,

gibt es im Eventlog des Servers vielleicht irgendwelche Hinweise - 
insbesondere
auch darauf, was seit "heute Mittag" mit der Maschine geschehen sein könnte?

Mit besten Grüßen,
  Till Warweg

-------------------------------------------------------------------- 

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
-------------------------------------------------------------------- 
"Steffen Schubert" wrote in message 
news:81395c3$64af54c$f65@news.alaska-software.com...

Hallo Jurac,

danke für den Tipp, aber Shellopenfile() geht nur für Prozesse, die
asynchron gestartet werden. Wenn ich auf das Ergebnis eines Prozesses
warten muss, kann ich nur Runshell() nehmen.

Grüße Steffen


Am 19.01.2015 um 13:57 schrieb "Matej Jurac":
> Ein 'Helfer', nicht uber RunShell, sondern uber ShellExecuteA, ist auch 
> fur's
> Dokumenten geeinigt und print, edit, etc.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
>
>
> //modes for run, 0 and 1 most used
> #define SW_HIDE             0
> #define SW_NORMAL           1
> #define SW_SHOWMINIMIZED    2
> #define SW_SHOWMAXIMIZED    3
> #define SW_MAXIMIZE         3
> #define SW_SHOWNOACTIVATE   4
> #define SW_SHOW             5
> #define SW_MINIMIZE         6
> #define SW_SHOWMINNOACTIVE  7
> #define SW_SHOWNA           8
> #define SW_RESTORE          9
> #define SW_SHOWDEFAULT      10
>
> PROCEDURE ShellOpenFile( cFile, nMode )
>
>         DllCall( "SHELL32.DLL"  , DLL_STDCALL, ;
>            "ShellExecuteA", AppDesktop():GetHWND(), "open", cFile, ;
>            NIL, CurDir(), nMode )
>
> RETURN
>
> Soll auch an Terminal Servers gut sein.
>

Wie sieht der Aufruf aus?

Grüße,

Werner

Ist zwar schon eine Weile her, aber ich nehme den Beitrag noch mal auf:

Runshell() bringt einen Fehler beim Aufruf CMD-Befehlen
Beispiel: Runshell(Runshell('/C START /MIN /WAIT Test.exe',,FALSE,TRUE))

Im Eventlog war nichts aussergewöhnliches zu finden.
Nach einigem Probieren haben wir festgestellt, dass die 
Environment-Variable "ComSpec" nicht mehr gesetzt war.
Ich habe die Variable wieder eingetragen (C:\Windows\System32), seitdem 
kommt keine Fehlermeldung von Runshell() mehr, ausführen tut er aber gar 
nichts.

Wenn ich die CMD.exe "mit der Hand" starte, tut er alles, was er soll.
Hat jemand das Problem schon mal gehabt, bzw. hat eine Idee, was es sein 
könnte?

Grüße Steffen

Am 19.01.2015 um 17:13 schrieb "Steffen Schubert":
> Hallo Jurac,
>
> danke für den Tipp, aber Shellopenfile() geht nur für Prozesse, die
> asynchron gestartet werden. Wenn ich auf das Ergebnis eines Prozesses
> warten muss, kann ich nur Runshell() nehmen.
>
> Grüße Steffen
>
>
> Am 19.01.2015 um 13:57 schrieb "Matej Jurac":
>> Ein 'Helfer', nicht uber RunShell, sondern uber ShellExecuteA, ist
>> auch fur's
>> Dokumenten geeinigt und print, edit, etc.
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
>>
>>
>>
>> //modes for run, 0 and 1 most used
>> #define SW_HIDE             0
>> #define SW_NORMAL           1
>> #define SW_SHOWMINIMIZED    2
>> #define SW_SHOWMAXIMIZED    3
>> #define SW_MAXIMIZE         3
>> #define SW_SHOWNOACTIVATE   4
>> #define SW_SHOW             5
>> #define SW_MINIMIZE         6
>> #define SW_SHOWMINNOACTIVE  7
>> #define SW_SHOWNA           8
>> #define SW_RESTORE          9
>> #define SW_SHOWDEFAULT      10
>>
>> PROCEDURE ShellOpenFile( cFile, nMode )
>>
>>         DllCall( "SHELL32.DLL"  , DLL_STDCALL, ;
>>            "ShellExecuteA", AppDesktop():GetHWND(), "open", cFile, ;
>>            NIL, CurDir(), nMode )
>>
>> RETURN
>>
>> Soll auch an Terminal Servers gut sein.
>>
>

Steffen,

>Runshell() bringt einen Fehler beim Aufruf CMD-Befehlen
>Beispiel: Runshell(Runshell('/C START /MIN /WAIT Test.exe',,FALSE,TRUE))

Ich habe dazu einige Fragen:

Was ist der Rückgabewert des Programs "Test.exe"? Ist es der Name eines 
anderen Programs das Du mit RunShell() aufrufen willst?

Ist dieses (zweite) Program im Pfad und kann es direkt aufgerufen werden?

Bist Du Dir ganz sicher, das "Test.exe" einen String Rückgabewert im 
Format: "/C START Program_Name.exe" hat? Der Aufruf der zweiten RunShell() 
würde dieses Format benötigen, um irgendwas zu tun.

Der Rückgabewert des Programs "CMD.exe" -- das Du in Wirklichkeit mit dieser 
RunShell() Schreibweise aufrufst -- ist immer eine Fehler Number. Das heißt 
das "RunShell('\C START...')" immer einen numerischen Wert zurückgeben wird!

Warum startest Du das "Test.exe" Program nicht direkt mit: 
"Runshell('', 'Test.exe', .f., .t.)", so daß es einen eigenen Rückgabewert 
haben kann? Das würde auch die "COMSPEC" variable überflüssig machen und Du 
würdest kein zusätzliches "CMD.exe" Kommandofenster öffnen.

Kannst Du uns ein wenig ausführlicher erklären was Du eigentlich erreichen 
möchtest? Vielleicht wolltest Du nur das "Test.exe" Program aufrufen, und 
die zweite, äußere "RunShell()" ist garnicht geplant? Brauchst Du einen 
Rückgabewert von diesem "Test.exe" Program?

Was passiert, wenn Du "Runshell('', 'Test.exe', .f., .t.)" benutzt?

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Hallo Andreas,

danke für deine ausführliche Antwort.
"Test.exe" gibt es nicht, es ist nur ein Beispiel.
Die Programme liegen immer im aktuellen Pfad und werden zur Sicherheit 
auch mit exakter Laufwerks- und Pfad-Angabe aufgerufen.
Wir haben einige externe Kommandozeilen-Tools, die minimiert ausgeführt 
werden sollen. Da wird manchmal nur ein Schalter gesetzt oder z.B. 
mehrere PDFs verknüpft und viele andere Dinge. Der Rückgabewert 
interessiert nicht, die Prozesse sollen nur minimiert starten und das 
Xbase-Programm soll warten, bis sie erledigt sind (deshalb ist auch 
Windows-Shellopenfile() nicht anwendbar).
Wie gesagt, es sind eine Menge ähnlich gearteter Aufrufe, die seit 
Jahren wunderbar funktionieren, nur seit Kurzem eben nicht auf diesem 
einen Terminalserver (Windows Server 2008).
Da diese Aufrufe aber nur unter Xbase++ nicht mehr funktionieren, habe 
ich die Frage hier im Forum gestellt.
Ich hatte die Hoffnung, dass vielleicht irgendjemand schon mal ein 
ähnliches Problem hatte oder zumindest eine Idee hat, was da mit 
passiert ist.

Grüße Steffen


Am 20.04.2015 um 12:41 schrieb "Andreas Gehrs-Pahl":
> Steffen,
>
>> Runshell() bringt einen Fehler beim Aufruf CMD-Befehlen
>> Beispiel: Runshell(Runshell('/C START /MIN /WAIT Test.exe',,FALSE,TRUE))
>
> Ich habe dazu einige Fragen:
>
> Was ist der Rückgabewert des Programs "Test.exe"? Ist es der Name eines
> anderen Programs das Du mit RunShell() aufrufen willst?
>
> Ist dieses (zweite) Program im Pfad und kann es direkt aufgerufen werden?
>
> Bist Du Dir ganz sicher, das "Test.exe" einen String Rückgabewert im
> Format: "/C START Program_Name.exe" hat? Der Aufruf der zweiten RunShell()
> würde dieses Format benötigen, um irgendwas zu tun.
>
> Der Rückgabewert des Programs "CMD.exe" -- das Du in Wirklichkeit mit dieser
> RunShell() Schreibweise aufrufst -- ist immer eine Fehler Number. Das heißt
> das "RunShell('\C START...')" immer einen numerischen Wert zurückgeben wird!
>
> Warum startest Du das "Test.exe" Program nicht direkt mit:
> "Runshell('', 'Test.exe', .f., .t.)", so daß es einen eigenen Rückgabewert
> haben kann? Das würde auch die "COMSPEC" variable überflüssig machen und Du
> würdest kein zusätzliches "CMD.exe" Kommandofenster öffnen.
>
> Kannst Du uns ein wenig ausführlicher erklären was Du eigentlich erreichen
> möchtest? Vielleicht wolltest Du nur das "Test.exe" Program aufrufen, und
> die zweite, äußere "RunShell()" ist garnicht geplant? Brauchst Du einen
> Rückgabewert von diesem "Test.exe" Program?
>
> Was passiert, wenn Du "Runshell('', 'Test.exe', .f., .t.)" benutzt?
>
> Andreas
>

Steffen,

>danke für deine ausführliche Antwort.

Gern geschehen.

>"Test.exe" gibt es nicht, es ist nur ein Beispiel.

Das habe Ich mir schon gedacht. Ich habe "Test.exe" als einen Platzhalter 
für Deinen eigentlichen Aufruf betrachtet.

Weil Du die folgende Frage nicht beantwortet hast, hier ist sie nochmal:

Was passiert, wenn Du "RunShell(cParameters, c_Program, .f., .t.)" benutzt?

Der erste Parameter von RunShell(), "cParameters", ist ein String mit allen 
Laufzeit Parametern für das gestartete Program.

Der zweite Parameter von RunShell(), "c_Program", ist ein String mit dem 
Namen (and Pfad) des Programs.

Der dritte Parameter von RunShell(), ".f.", sorgt dafür das RunShell() 
wartet bis dein Program beendet ist.

Der vierte Parameter von RunShell(), ".t.", sorgt dafür das dein Program im 
Hintergrund (minimiert) gestartet wird.

Das aufgerufene Program kann sich naturlich selbst in den Vordergrund 
bringen oder ein maximiertes Fenster öffnen, aber das kannst Du ja in 
keinem Fall verhindern.

Kannst Du das mal ausprobieren und uns wissen lassen ob es funktioniert?

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net