IPS_Execute reagiert nicht

Mir gelingt es unter Windows 10 nicht, über IPS_Execute(Ex) ein Programm zu starten. Es passiert schlicht gar nix.

Ich habe bereits die (laut Doku) verschiedenen Pfadschreibweisen durchprobiert:

IPS_Execute("C:/Windows/notepad.exe", "", false, false);
IPS_ExecuteEx("C:/Windows/notepad.exe", "", false, false, -1);
IPS_Execute("C:\\Windows\
otepad.exe", "", false, false);
IPS_ExecuteEx("C:\\Windows\
otepad.exe", "", false, false, -1);

Da die IPS-Tools offenbar nicht über eine Remoteverbindung ausgelöst werden („IPSTools_SetScreenPower(false)“ schaltet den Monitor nicht ab), habe ich alles auch direkt am IPS-Rechner probiert (dann funktionieren die IPS-Tools). IPS_Execute(Ex) löst trotzdem keine Reaktion aus. Ich sehe auch keine Fehlermeldung.

Die im Forum besprochenen Probleme (Parameter, …) sind m.E. keine Treffer, denn dort funktioniert es ja zumindest im Grundsatz.

Ich vermute eine banale Dussligkeit meinerseits, komm aber nicht drauf. :wink:

Grüße
galleto

Hallo Freunde,

ich habe seit dem Update auf 4.0 ein kleines Problem mit meinen zahlreichen IPSExecuteEx Befehlen in scripten. Ich habe bisher folgendes verwendet:

IPS_ExecuteEx("nircmd.exe","changesysvolume 6553",false,false,-1);

Die auszuführende Datei nircmd.exe hatte ich im IP-Symcon Verzeichnis → keine Probleme. Seit dem Update kommt der Fehler:
Warning: File does not exist in [Musik\Lauter] on line 16

Jetzt habe ich romprobiert und es funktioniert so:

IPS_ExecuteEx("C:/IP-Symcon/nircmd.exe","changesysvolume -1",false,false,-1);

Wurde da was geändert? Auf welches Verzeichnis bezieht sich der Befehl ohne Pfadangabe?
Gruss
TK

Hab mir die Logs nochmal angesehen, es passiert schon was:

16:43:41 | 10395 | DEBUG | ScriptEngine | Executing Script 10395 ~ Sender: Execute
16:43:41 | 10395 | DEBUG | ScriptEngine | Executed Script 10395 ~ Sender: Execute

Für IPS scheint Execute offenbar erfolgreich ausgeführt worden zu sein, oder? Trotzdem wird kein Programm gestartet. :confused:

Wenn ich absichtlich eine nicht existentes Programm (notepad2.exe) starte, kommt allerdings derselbe Log-Eintrag.

Wo könnte ich die Fehlersuche ansetzen?

Grüße
galleto


IPS_ExecuteEx("C:\\Windows\
otepad.exe", "", true, false, -1);

Der erste Parameter (ShowWindow) muss TRUE sein, sonst siehst du ja nix :smiley:

@TK6: Das schaue ich mir an

paresy

Danke paresy, Dein Hinweis ist bezogen auf meine Angaben natürlich berechtigt. Aber ich wollte nur die Pfadschreibweisen verdeutlichen und habe dafür das Beispiel von IPS_ExecuteEx aus der Doku genommen. Ein versteckter Aufruf der notepad.exe ist tatsächlich etwas albern, könnte man vielleicht auch in der Doku anpassen… :wink:

Wie auch immer, machen wir es konkret - Folgendes funktioniert bei mir nicht:

IPS_Execute(„C:/IP-Symcon/touch_aus.bat“, „“, false, false);
IPS_Execute(„C://IP-Symcon//touch_aus.bat“, „“, false, false);
IPS_Execute(„C:\IP-Symcon\ ouch_an.bat“, „“, false, false);
IPS_Execute(„C:\IP-Symcon ouch_an.bat“, „“, false, false);

Und das hier funktioniert:

IPS_ExecuteEx(„C:\IP-Symcon\ ouch_aus.bat“, „“, true, false, -1);
IPS_ExecuteEx(„C:\IP-Symcon\ ouch_aus.bat“, „“, false, false, -1);

Daher die Frage: Was mach ich bei „IPS_Execute“ verkehrt bzw. hab ich falsch verstanden?

Grüße
galleto

Die Frage ist eher: Was macht deine Batch Datei? Wenn das Programm dahinter eine User Session brauchst, musst du ExecuteEx nutzen. Execute läuft im Hintergrund mit System Rechten und kann also ggf. nicht laufen. Du kannst damit ja auch kein notepad sichtbar öffnen.

paresy

Die touch_xxx.bat ruft eine (selbst erstellte) *.exe auf, die einen USB-Port (de-)aktiviert.

Die *.exe greift also ins System ein, braucht (und hat) daher Sonderrechte; die *.bat dürfte aber den Exe-Aufruf auch ohne Sonderrechte schaffen. Genau deswegen habe ich sie ursprünglich dazwischen geschaltet.

Unter Version 3.4 (und Windows 7) funktionierte folgende Zeile noch:

IPS_Execute("C:/IP-Symcon/touch_aus.bat", "", false, false);

Jetzt geht das nicht mehr. Das kann freilich auch an Windows 10 liegen, aber das scheint mir nicht zwingend. Egal: Da ich mit IPS_ExecuteEx eine funktionierende Lösung habe, können wir es dabei belassen, wenn das beschrieben Verhalten nach Deiner Einschätzung kein Bug ist.

Danke für Deine Erläuterungen!

Grüße
galleto