StartWin()

[Zeuge]

Hallo

Ich nutze einigermaßen rege die Funktion StartWin(xx.exe).
Leider wartet Homeputer auf das Ende des gestarteten Programmes.
Nach kurzer Zeit gibt es natürlich den Fehler : Laufzeitüberschreitung im Macro.

In der Hilfe.chm schreibt Ihr als Beispiel:

Code: Alles auswählen

STARTWIN("C:\FAX\SENDEFAX.EXE HEIZUNGSSTOERUNG")

Das glaubt Ihr ja wohl selbst nicht?
So schnell ist kein Fax raus wie es eine Fehlermeldung von Homeputer gibt.

Also wie funktioniert das Starten externer Anwendungen ohne deren Ende abzuwarten?

[contronics-RK]

Grundsätzlich ist es so, dass durch diese Anweisung nicht auf das Ende des aufgerufenen Programms gewartet wird.
Ab dem neusten Update wird für diese Anweisung die Windows-API Shellexecute verwendet. In der aktuellen Version wird noch WinExec verwendet.
Wir konnten das "Anhalten" selbst mit alten DOS-Programmen bei keiner der Methoden reproduzieren.
Es kann eigentlich nur an sehr speziellen Progarmmen liegen, die dort aufgerufen werden und wahrscheinlich keinen eignen Windows-Task benutzen.

Mit freundlichem Gruss
contronics - Ralph Krapoth

[gwanjek]

Es kann eigentlich nur an sehr speziellen Progarmmen liegen, die dort aufgerufen werden und wahrscheinlich keinen eignen Windows-Task benutzen.

Wenn ein Tochterprozeß läuft, ist die Entscheidung, ob der Mutterprozeß darauf wartet, längst gefallen. Diese liegt AUSSCHLIEßLICH beim Mutterprozess und der Methode der Initiierung eines eben abhängigen (modalen?) oder unabhängigen Childs. Insofern kann das oben zitierte niemals zutreffen.

Gruß Gerd

[contronics-RK]

Bitte doch einfach mal ausprobieren - wir haben es nach Meldung dieses Problems mit etlichen (auch alten DOS-) Programmen versucht und keins gefunden wo gewartet wurde. Mit Sicherheit ist das Warten nicht auf die Studio-Version oder den verwendeten API-Aufruf zurückzuführen. Würde dieses "Warten" beim Aufruf von der Studio-Version initiiert müsste es grundsätzlich so sein.
Die verwendeten APIs starten einen separaten Task, ein Child dagegen ist normalerweise ein Fenster innerhalb eines Tasks.

Freundliche Grüsse
contronics - Ralph Krapoth

[Zeuge]

Ich verwende eine selbst erstellte Exe die eine Netzwerkverbindung herstellt und nach 50sec. Wartezeit weiteres erledigt.

Code: Alles auswählen

Der Code schaut so aus:
Global Port = 10102
Global AuszugebenderText.s ="txt2osd -r -d 0 -x -1 -y -1 -s 68 " ,IP.s  = "192.168.1.8" 

Procedure TextAnTV()

ConnectionID = OpenNetworkConnection(IP, Port)
If ConnectionID
  SendNetworkString(ConnectionID, AuszugebenderText)
CloseNetworkConnection(ConnectionID)
EndIf
 
EndProcedure

If InitNetwork() = 0
  MessageRequester("Error", "Netzwerk kann nicht initialisiert werden !", 0)
  End
EndIf

AuszugebenderText = "txt2osd -r -d 0 -x -1 -y -1 -s 68 Das ist der BVlahblah bla Text"
TextAnTV()
Delay(50000)

End 

Diese Exe steht dann auch schön im Taskmanager, verrichtet brav ihre Arbeit.
Allerdings ist das Teil ohne Oberfläche usw. - arbeitet im Hintergrund.

Selbst wenn ich die Exe über eine *.Bat von Homeputer aus aufrufe erhalte ich die Fehlermeldung.
Homeputer bekommt während der Laufzeit des Programmes auch keine Statusänderungen mehr mit, was ja klar ist wenn Homeputer das Taskende abwartet.
Prozessauslastung ist während der Laufzeit der Exe gering..

Allerdings scheint der Fehler nicht immer zu passieren, habe aber noch keine Zusammenhänge erkannt.

Edit: Der Fehler wird nur in der Statusleiste der Ansicht signalisiert.
Ein *.Log oder ähnliches gibt es nicht.

Laufzeitfehler in Macroxxx steht dann in der Statusleiste für ca. 5sec.

[gwanjek]

Nur mal als Idee: Kann das vielleicht damit zusammenhängen, daß der Zeuge ja wohl offenbar VISTA einsetzt?

Es kann eigentlich nur an sehr speziellen Progarmmen liegen, die dort aufgerufen werden und wahrscheinlich keinen eignen Windows-Task benutzen.

Ähm... Wie soll das bitte gehen? Aufruf eines Programms, ohne dass das als Prozeß läuft?

Die verwendeten APIs starten einen separaten Task, ein Child dagegen ist normalerweise ein Fenster innerhalb eines Tasks.

Was bitte haben Tasks und Prozessen mit Fenstern zu tun??? Ich kenne Prozesse nur als Prozesse, egal ob die nun Fenster oder Türen oder gar nix aufmachen. (Höchstens: Zeitfenster) Aber sehr wohl sind diese z.B. unter Windows im Taskmanager als erstmal prinzipiell unabhängige voneinander existierend erkennbar und jeweils mit eigener PID (=Prozess-ID) ausgestattet.

Und: Wenn nun ein Parent-Prozess ein Child-Prozess initiiert, entscheidet immer dieser allein, ob er nun auf sein Kind wartet oder nicht. Wenn das Kind erstmal geboren ist und rumrennt, kann es sich nicht mehr aussuchen, ob seine Eltern bei seiner Geburt weggelaufen sein sollen oder nicht Es sei denn, das Kindchen beherrscht die Umdrehung des Kausalitätsprinzips, was sicher zumindest Nobelpreiswürdig wäre.

Ob diese Prozesse also doch miteinander kommunizieren und gar aufeinander warten, also eine IPC aufbauen (=InterProcessCommunication) MUß der Parent-Prozess entscheiden (üblicherweise per Wahl der Aufrufmethode / API-Call / Befehl). Und sicher kann dann wiederum dem Child mitgegeben werden, über eben diese IPC wiederum auf den Parent-Prozess zu wirken (was dieser aber ebenfalls erstmal zulassen muß!) Und hat die Studio-SW intern Halt-Reaktionen, die per IPC-Signal vom Child initiiert werden? Sicher nicht, denn dazu wären dann definierte Protokolle notwendig (z.B. Netzwerkprotokolle funktionieren so in den unteren Schichten der Treiber)

Hier ein Link zu der entsprechenden Dokumentation der zugehörigen Befehle, hier unter Perl (dort: Exec, Fork, System), die auch im Port unter Windows so anwendbar sind. Ergo ordnen sich auch die Windows-API's diesem Prozeßhandling unter. Logisch, Windows will ja multitaskingfähig sein. Und auch mit Netzwerken u.ä. umgehen können.

Gleiches gilt dann doch wohl auch für die wiederum auf diesem Betriebssystem laufenden Anwendungsprogramme, oder etwa nicht?

Gruß Gerd.

[Zeuge]

Tja nö.

Ich sah mich nur genötigt soviel Information wie möglich abzuliefern.

[Zeuge]

Mister Merkwürden.

Nach meinen Update von 70122 auf 70266 haut es wieder mit dem Starten externer Anwendungen hin.
Homeputer arbeitet weiter, generiert keine Fehlermeldung - super.

Edit:
So einfache Sachen wie Schalter - Ausführen bei Änderung:

Code: Alles auswählen

StartWin("C:\Windows\system32\notepad.exe C:\Program Files\contronics\homeputer Studio\IOLog.txt")

gehen leider nicht mehr.

Anscheinend wird die Funktion StartWin() nicht ausgeführt wenn nach dem zu startendem Programm noch Parameter folgen.

Denn folgende Sequenz geht:

Code: Alles auswählen

StartWin("C:\Windows\system32\notepad.exe")

[contronics-RK]

Die Ursache ist sicherlich, dass Vista (wie auch von MS angekündigt) die API WinExec nicht mehr unterstützt. Deshalb wird in der aktuellen Version auch die neuere API Shellexecute verwendet.
Dieser Aufruf hat den Vorteil, dass auch einfach nur eine Datei mit registrierter Endung angegeben werden kann - das Programm wird dann automatisch aufgerufen. Es ist allerdings noch ein Fehler in der neuen Version: Dort ist nicht berücksichtigt, dass Parameter separat übergeben werden müssen. Wahrscheinlich morgen kommt eine entsprechend berichtigte Version auf die Downloadseite. Dann funktionieren auch die Parameter wieder.

Mit freundlichem Gruss
contronics - Ralph Krapoth

[Zeuge]

Version 70229
Funktion StartWin macht noch Probleme mit Parameter

Code: Alles auswählen

AllgemeineSystemVariablen.TempDatei:="Explorer.exe C:\Eigene Dateien\Funk-Haus-Steuerung\SPG"
StartWin("Explorer.exe C:\Eigene Dateien\Funk-Haus-Steuerung\SPG")
StartWin(AllgemeineSystemVariablen.TempDatei)

Ergebnis sind zwei Explorer-Fenster mit Verzeichnis C:\Program Files\contronics\homeputer Studio\SPG und nicht wie gewünscht in C:\Eigene Dateien\Funk-Haus-Steuerung\SPG

Wenn ich das SPG-Verzeichnis aus dem Programme\Contronics Verzeichnis lösche gehen keine Explorer-Fenster mehr auf.
Alle anderen StartWin-Funktionen mit Parameter funktionieren auch nicht.

Muss ich den Aufruf jetzt anders gestalten oder...

Vielen Dank für die Unterstützung