Discussion :

[mercure07]

Bonjour tout le monde, j'ai une application qui lors de son démarrage lance une 2ème application en tant que processus. Pour cela j'ai utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

QProcess::startDetached("UpdaterApp.exe");

.
Dans mon menu j'ai une icone depuis laquelle je peux lancer cette même 2ème application (qu'est une application de mise à jour de base de donné).
Avant de lancer l'application, je fais un test si elle est déjà lancée ou pas.
Dans le cas où elle est lancée, je désire afficher la fenêtre (dialog) de l'application.
Est ce quelqu'un pourrait me dire si c'est faisable et si oui comment faire.
Merci d'avance pour votre collaboration.
Cordialement

[Fabllot]

Bonjour,

A priori tu ne peux pas contrôler directement les widgets d'une application par une autre... Par contre tu peux dire à ta seconde application qu'elle a la main et qu'elle doit s'afficher au premier plan...
Et ce tu peux le faire grâce à une petite communication inter-pocessus avec des sockets par exemple...

[mercure07]

Merci de votre réponse, en fait j'ai bcp cherché et j'ai trouvé que c'est pas possible de contrôler ou d'appeler la 1ère application qui est deja en cours.
Mais est ce que vous pouvez me détailler davantage votre solution que ce soit par du code et/ou exemple.
Merci encore.
Cordialement

[Fabllot]

Il faut utiliser le module "NetWork" et plus particulierement les classes QTcpSocket & QTcpServer...

La seconde application ouvre un socket serveur sur un port prédéfini dès son démarrage.
Quand la première appli veut communiquer avec la seconde, elle ouvre un socket client sur le même port : Deux cas sont alors possible. Soit la connexion échoue ce qui signifie que la seconde application n'est pas en cours d'exécution, soit la connexion réussie et la premiere appli peut donner à la 2e des infos sous forme de QByteArray ou de char* (méthode "write" de QIODevice)...

Voir les exemples du module Network dans la doc Qt...

[yan]

Salut

Merci de votre réponse, en fait j'ai bcp cherché et j'ai trouvé que c'est pas possible de contrôler ou d'appeler la 1ère application qui est deja en cours.

Que veut tu dire par "contrôler ou d'appeler"?

[mercure07]

C'est contrôler la fenêtre de l'application et l'appeler pour l'afficher

[yan]

Vue que tu le lance par process, peut être que cela peut t'intéresser :

http://qt.developpez.com/faq/?page=q...ir_application
http://qt.developpez.com/faq/?page=q...ation_Qprocess

[FloMo]

Si chaque application est développée par tes soins, tu peux utiliser QSharedMemory.

Exemple ici

[yan]

Si chaque application est développée par tes soins, tu peux utiliser QSharedMemory.

Exemple ici

Ce que j'ai compris:
il veut manipuler l'ihm (aficher caher, ...) de l'ihm lancé par process.
Je ne pense pas que ce soit aussi simple avec qsharedmemory, car on veut donner des ordres. Passer par des pipe ou par un soket et pour moi une meilleur solution.

S'il veut partager de grosse donné entre appli, alors qsharedmemory est surement une solution intéressante.

[Aurelien.Regat-Barrel]

Ce que j'ai compris:
il veut manipuler l'ihm (aficher caher, ...) de l'ihm lancé par process.
Je ne pense pas que ce soit aussi simple avec qsharedmemory, car on veut donner des ordres. Passer par des pipe ou par un soket et pour moi une meilleur solution.

pipe, socket, shared memory ne sont que des mecanismes d'IPC permettant a 2 applications de discuter. Mais pour discuter, il faut etre deux.

Si l'application cliente n'est pas developpee par lui, aucun de ces mecanismes ne lui sera utilise vu que l'appli n'a pas ete codee pour etre pilotee.

Il faut passer par le systeme de fenetrage pour la manipuler en simulant des actions utilisateurs. Sous Windows, AutoIt peut faciliter cela. Mais cela aussi de l'application cliente et du toolkit GUI qu'elle utilise.

[yan]

Si l'application cliente n'est pas developpee par lui, aucun de ces mecanismes ne lui sera utilise vu que l'appli n'a pas ete codee pour etre pilotee.

Si il ne l'as pas développé, sont appli à surement une manière de communiquer, au moins par entrée/sortie standard (exemple de l'exe cvs). Sinon, oui il est mal barré.

Il faut passer par le systeme de fenetrage pour la manipuler en simulant des actions utilisateurs. Sous Windows, AutoIt peut faciliter cela. Mais cela aussi de l'application cliente et du toolkit GUI qu'elle utilise.

C'est facile à utilisé?

[Aurelien.Regat-Barrel]

Si il ne l'as pas développé, sont appli à surement une manière de communiquer, au moins par entrée/sortie standard (exemple de l'exe cvs). Sinon, oui il est mal barré.

Comme il parle d'un dialogue, j'ai pas pense a une application console. Si c'est le cas, en effet piloter l'appli via QProcess en laissant Qt rediriger les flux stdin/stdout via des pipes sera tres simple.

Si il ne l'as pas développé, sont appli à surement C'est facile à utilisé?

Je n'ai utilise Auto-it qu'en temps qu'appli normale, et oui c'est plutot simple a utiliser. L'avantage d'Auto-it, c'est que tu peux l'embarquer dans ton appli. J'ai jamais teste, mais je pense que ca doit rester beaucoup plus simple que de faire tout le boulot via du code Win32.