qtforum.de

Hallo,

ich habe eine Qt4.4.0-Applikation, die über einen übergeordneten Prozess angetriggert wird. Meine Applikation durchläuft dabei stets dieselben Funktionen, wird nur mit stets anderen Parametern aufgerufen. Leider kann ich an der Parent-Applikation nichts ändern, weshalb ich durch Änderungen im Unterprozess (meiner Applikation) angewiesen bin.

Zurzeit sieht es so aus, dass sich meine Applikation versteckt im Tray-Bar startet. Man sieht also nur Anhand des Task-Managers und des Tray-Icons, dass die Applikation läuft. Anfangs hatte ich es so für richtig gehalten, allerdings nervt dieses "geblinke" schon nach kurzer Zeit. Ständig fügt sich das Tray-Icon hinzu, und verschwindet wieder.

Ist es nun irgendwie möglich, dass wenn der Prozess einmal gestartet ist, ich ihn nach Beendigung seiner Tätigkeit nicht schließe (das dürfte kein Problem darstellen) sondern im Tray-Bar aufrecht erhalte; er aber nicht x-Mal aufgerufen wird (wie gesagt wird der Prozess durch einen übergeordneten Prozess gestartet) sondern einfach nur die Prozedur, die er zu durchlaufen hat, angeschmissen wird?

Ich kann das jetzt schwer in Worte fassen, da ich kein Stichwort dazu kenne.

Der Wunsch ist also:
- Die Applikation (der Prozess) wird gestartet
- Macht seine Abhandlung
- Fährt in eine Art Ruhezustand
- Startet seine Abhandlung erneut (mit neu übergebenen Parametern) indem der Prozess wieder angeschmissen wird (geschieht über eine alte Qt3.11 Applikation per QProcess)
- Fährt wieder in den Ruhestand
usw.

Ich hoffe das war halbwegs verständlich. Falls Fragen bestehen, einfach raus damit. Falls Hilfe, ebenfalls.




Mfg KK

Ich kenne einige Implementierungen bei denen sowas mit einem Launcher gemacht wird.

Ablauf:

* Übergeordneter Prozess ruft Launcher auf mit Parametern
* Launcher prüft, ob die Worker-Applikation bereits gestartet ist und startet sie ggf.
* Launcher übergibt die neuen Parameter (z.B. über UDP/TCP) an den Worker und beendet sich wieder
* Worker arbeitet den Job ab und legt sich dann schlafen (wartet auf readyRead-Signal der Netzwerkklasse)


Der Launcher sollte aus minimalem Quellcode bestehen, damit es einfach schnell geht. Der Worker erzeugt das Tray-Icon. Da der Worker nicht mehr beendet wird, flackert auch nix mehr.


Ciao,
Sephral

Nachtrag: Auf die Weise kann man auch gleich ne praktische Job-Queue aufbauen

Wenn du an der "Trigger Application" nix aendern kannst, wird es bei dem hochziehen des prozesses immer bleiben ....

Ich nehm mal an, deine "Triggerapplication" ruft mit fork/system oder aehnlichem den prozesses von dir auf ...

Um die sache zu entkoppeln, kannst du eigentlich nur folgendes machen:
einen 3.Prozess ins spiel bringen.
Also deine Application so bauen, dass sie sich im system (tray) permanent verankert, und aber ueber IPC mechanismen, RPC z.b. oder sockets, Jobs ferngesteuert werden kann.
Als 3. application dann einfach eine sipmple App, die von der Trigger App aufgerufen wird, und die argumente umsetzt und damit deine App steuert.

sondern einfach nur die Prozedur, die er zu durchlaufen hat, angeschmissen wird

wird nicht gehen .... du kannst zwar prozesse suspendieren, aber nen system-call so umzuleiten, das es keinen neuen prozess startet sondern nen vorhandenen reaktiviert und ueber main neu einspringt, glaub das sind zu tiefe einschnitte ins system.

Ciao ....

Nachtrag: Auf die Weise kann man auch gleich ne praktische Job-Queue aufbauen

Ich muss schmunzeln, denn genau das ist die Parent-Application. Die Ideen sind sehr gut, nur leider habe ich gerade erfahren, dass ich es so nicht verwenden kann. Da die übergeordnete Applikation eine Prozess-Queue aufbaut, wird ein neuer Prozess erst aufgerufen, wenn der zuletzt gestartete sich beendet hat.

Eine Launcher-Funktionalität würde so also nicht korrekt funktionieren, da sie bloß den Worker antriggert und sich dann wieder schließt. Die Prozess-Queue würde also den nächsten Prozess anschmeißen, da der untergeordnete (der Launcher) beendet ist. Der Worker allerdings läuft noch, was somit nicht mehr im Sinne des Erfinders ist.

Um das ganze Elend zu dämmen, reduziere ich meinen Unterprozess soweit, dass man nicht mehr sieht, dass er startet und schließt. Mit dem Overhead eines jeden Starts muss ich leben.

Wie gesagt danke ich Euch für die Hilfe, ich hätte es auch fast so gemacht.



Mfg KK

Naja, ist doch kein Hinderniss eigentlich ....
Der launcher kann ja quasi warten, bis der Job sich in deinem Workerprozess beendet hat .... und sich dann auch erst selbst beenden.

Dann hasst haargenau die alte funktionalitaet, nur mit dem zwischenprozess, und dem entkoppelten Worker Prozess, der halt permanent nu laeuft.

Damit waer zumindest dein traybar problem geloest ^^

Ciao ...