communication entre 2 applications (exe)

Version imprimable

Bonjour,
Quelle méthode dois je utiliser pour communiquer entre 2 .exe ?
Mon contexte:
-2 applications MFC A & B
-j'aimerais que l'application A envoi un message à l'application B pour lui demander de s'arrêter (proprement...)
-l'application B doit donc scruter ce genre de message afin de déclencher sa fermeture...
-j'utilise actuellement le code ci-dessous dans l'application A afin de déclencher un traitement quand l'application B se termine, mais j'aimerais "précipiter" cette terminaison
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // code de l'application 'A' bool CUpdaterApp::Wait() { HANDLE hSnapShot; PROCESSENTRY32 uProcess; BOOL r; short PID = 0; hSnapShot = CreateToolhelp32Snapshot(TH32CS_SNAPALL,0); uProcess.dwSize = (DWORD) sizeof(PROCESSENTRY32); r = Process32First(hSnapShot, &uProcess); do { if ( strstr(uProcess.szExeFile, "B.exe") ) // on compare au nom de l'executable PID = (short) uProcess.th32ProcessID; r = Process32Next(hSnapShot, &uProcess); } while ( r ); CloseHandle(hSnapShot); if ( PID == 0) return false; HANDLE hTemp; hTemp = OpenProcess(PROCESS_ALL_ACCESS, false, (DWORD) PID); WaitForSingleObject( hTemp, INFINITE ); DWORD retour; GetExitCodeProcess(hTemp,&retour); CloseHandle( hTemp ); return(true); }
j'espère avoir été clair...

18/10/2006, 13h59
Médinoc

Ce sont des applications console (difficile) ou fenêtrées (facile) ?
18/10/2006, 14h21
farscape

voir déjà la faq:
http://c.developpez.com/faq/vc/?page...ad#ProcessKill
18/10/2006, 14h30
hal9000

Citation:

Envoyé par Médinoc

Ce sont des applications console (difficile) ou fenêtrées (facile) ?

c'est une application fenêtrées et l'application B a été "lancée" par l'application A via createprocess.
18/10/2006, 14h43
farscape

alors tu as ta reponse dans la faq...
18/10/2006, 16h06
Médinoc

Euh... J'ai des doutes sur cette entrée de la FAQ...
WM_CLOSE sert à ordonner de fermer une fenêtre (SYSCOMMAND(SC_CLOSE) entraîne WM_CLOSE qui entraîne DestroyWindow()), si j'ai bien compris l'aide. Il faudrait donc plutôt envoyer ce message vers une fenêtre (trouvée avec FindWindow() par exemple), non?

WM_QUIT, par contre, termine un thread UI en forçant la sortie de sa MessageLoop...
18/10/2006, 16h12
farscape

Citation:

Envoyé par Médinoc

Euh... J'ai des doutes sur cette entrée de la FAQ...
WM_CLOSE sert à ordonner de fermer une fenêtre (SYSCOMMAND(SC_CLOSE) entraîne WM_CLOSE qui entraîne DestroyWindow()), si j'ai bien compris l'aide. Il faudrait donc plutôt envoyer ce message vers une fenêtre (trouvée avec FindWindow() par exemple), non?

WM_QUIT, par contre, termine un thread UI en forçant la sortie de sa MessageLoop...

voir note MSDN:
http://support.microsoft.com/default...EN-US;Q178893&
19/10/2006, 09h52
Médinoc

Citation:

Envoyé par Microsoft KB

Post a WM_CLOSE to all Top-Level windows owned by the process that you want to shut down.

Citation:

Envoyé par Microsoft KB

Once you have established a match, use PostMessage() or SendMessageTimeout() to post the WM_CLOSE message to the window.

Cela supporte ce que je dis: WM_CLOSE est à envoyer aux fenêtres, pas à un thread...

1 pièce(s) jointe(s)

le thread principal d'une application fenetrée dispose d'une pompe a messages
je peux donc bien faire ce que j'ai dit meme si le WM_QUIT est à préférer que WM_CLOSE ,dans l'absolu et suivant les cas on pourra meme utiliser WM_DESTROY....

un petit exemple fabriqué rapidement:
programme pour fermer un processus à partir du nom de fenêtre.
programme en mode console avec support des MFC.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
 
// KillProcess.cpp : Defines the entry point for the console application.
//
 
#include "stdafx.h"
#include "KillProcess.h"
 
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
 
/////////////////////////////////////////////////////////////////////////////
// The one and only application object
 
CWinApp theApp;
 
using namespace std;
 
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
    int nRetCode = 0;
 
    // initialize MFC and print and error on failure
    if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
    {
        // TODO: change error code to suit your needs
        cerr << _T("Fatal Error: MFC initialization failed") << endl;
        return  1;
    }
 
    // TODO: code your application's behavior here.
    if(argc<2)
    {
        cout << _T("KillProcess utilisation: KillProcess Nom de la fenetre") << endl;
        return 0;
    }
    CString strWindowName=GetCommandLine();
    int nPos=strWindowName.ReverseFind('"');
    strWindowName=strWindowName.Mid(nPos+2);
 
    cout << _T("Recherche Fenetre:") << (LPCSTR) strWindowName ;
 
    HWND hWnd=FindWindow(NULL,strWindowName);
    cout << _T(" :") << (hWnd?_T("Trouvee !!"):_T("Non Trouvee!!")) << endl;
    if(!hWnd) return 0;
 
    CString str;
    str.Format(_T("FindWindow: 0x%xh"),hWnd);
 
    cout << (LPCSTR) str << endl;
    DWORD dwProcessId;
    DWORD hThread = GetWindowThreadProcessId(hWnd,&dwProcessId);
    str.Format(_T("GetWindowThreadProcessId: 0x%xh Process 0x%xh"),hThread,dwProcessId);
 
    cout <<(LPCSTR) str << endl;
 
    cout << _T("Envoi PostThreadMessage de WM_QUIT ...") << endl;
    PostThreadMessage(hThread,(UINT) WM_QUIT,0,0);
    cout << _T("Termine !") << endl;
    return nRetCode;
}

19/10/2006, 12h12
Médinoc

Un message posté avec PostThreadMessage() possède un HWND NULL.

Citation:

Envoyé par [URL=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/postthreadmessage.asp]MSDN : PostThreadMessage[/URL]

The thread to which the message is posted retrieves the message by calling the GetMessage or PeekMessage function. The hwnd member of the returned MSG structure is NULL.
Messages sent by PostThreadMessage are not associated with a window. As a general rule, messages that are not associated with a window cannot be dispatched by the DispatchMessage function. Therefore, if the recipient thread is in a modal loop (as used by MessageBox or DialogBox), the messages will be lost. To intercept thread messages while in a modal loop, use a thread-specific hook.

Donc, le WM_CLOSE ou WM_DESTROY (ce dernier étant un hack, puis qu'il fait croire à la fenêtre qu'elle se détruit alors que ce n'est pas le cas) envoyé par PostThreadMessage() sera perdu par DispatchMessage() et la pompe à message du thread continuera. Seul WM_QUIT peut faire retourner 0 à GetMessage() et stopper ainsi la pompe.

rebonjour,
alors suite à vos diverses réponse, j'ai essayé plusieurs petites choses, mais en gros, j'ai toujours mon problème...

a) le code

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    HWND hWnd=FindWindow(NULL,"A.exe");
    if(!hWnd)
    {
        AfxMessageBox("echec findwindow",MB_ICONEXCLAMATION|MB_OK|MB_DEFBUTTON1);
        return;
    }
    AfxMessageBox("findwindow ok",MB_ICONEXCLAMATION|MB_OK|MB_DEFBUTTON1);
 
    DWORD dwProcessId;
    DWORD hThread = GetWindowThreadProcessId(hWnd,&dwProcessId);
    BOOL bRet;
    bRet=::PostThreadMessage(hThread,(UINT) WM_QUIT,0,0);
    if(!bRet)
    {
        AfxMessageBox("echec PostThreadMessage",MB_ICONEXCLAMATION|MB_OK|MB_DEFBUTTON1);
    }

part toujours en "echec findwindow"... alors que l'application 'A' est bien active

b) j'ai essayé le code

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
    char szIdentite[]="A.exe";
    CWnd* pWnd = CWnd::GetDesktopWindow( )->GetTopWindow( );
    CWnd *pWndApp = 0;
    CString s,strApp;
    while( 1 )
    {
        pWnd = pWnd->GetNextWindow();
        if ( pWnd == NULL ) break;
        pWnd->GetWindowText( s );
        strApp=s;
        if(strApp.Find(szIdentite)!=-1)
        {
            pWndApp = pWnd;
            break;
        }
    }
    if(pWndApp)
    {
        AfxMessageBox("Application trouvée",MB_ICONEXCLAMATION|MB_OK|MB_DEFBUTTON1);
        ::PostMessage(pWndApp->GetSafeHwnd(),WM_SYSCOMMAND, SC_CLOSE, 0L );
    }
    else
    {
        AfxMessageBox("Application non trouvée",MB_ICONEXCLAMATION|MB_OK|MB_DEFBUTTON1);
    }

part toujours en "application non trouvée"

c) j'ai une question complémentaire:

comment intercepter WM_QUIT sur l'application 'A' (quand j'aurais réussi à envoyer le message...)
en effet, je ne vois pas WM_QUIT dans le classwizard sur la classe d'application (alors que je vois WM_CLOSE)

23/10/2006, 14h03
farscape

salut,
il me semble que tu n'as pas besoin de chercher la fenêtre puisque c'est toi qui lance le process b, tu disposes donc de tous les éléments pour faire le PostThreadMessage comme indiqué dans le post de la faq (cité plus haut), et en mettant WM_QUIT.
23/10/2006, 14h08
Médinoc

WM_QUIT n'est pas interceptable: Il termine la boucle de messages et le thread destinataire reprend son exécution après la boucle.
(C'est-à-dire, dans le cas d'un programme MFC Dialog-Based, après le DoModal()).

Le second paramètre de FindWindow() ne doit pas être le nom de l'exécutable, mais le titre de la fenêtre.
23/10/2006, 14h17
hal9000

Citation:

Envoyé par Médinoc

WM_QUIT n'est pas interceptable: Il termine la boucle de messages et le thread destinataire reprend son exécution après la boucle.
(C'est-à-dire, dans le cas d'un programme MFC Dialog-Based, après le DoModal()).

Le second paramètre de FindWindow() ne doit pas être le nom de l'exécutable, mais le titre de la fenêtre.

-merci, c'est ok pour findwindow()...
-pour wm_quit, mon application 'A' est en MFC MDI...
23/10/2006, 14h46
Denn's

Salut,

tu pourrais essayer le truc suivant:
- process A crée un sémaphore.
- process A lance process B en lui indiquant le sémaphore ( si je me souviens
bien, tu lui passe ds un des args de CreateProcessus() sous forme d'une
adresse - un truc comma ça - ( process A détient le sémaphore à ce
moment là ).
- Quand process A n'a plus besoin de process B, alors il relâche le sémaphore
=> Process B le récupère et "comprends" qu'il doit s'auto-terminer.

Sinon, si tu veux garder les messages, essaie de voir la MSDN mais du coté
"SetEvent()", "PulseEvent()","ResetEvent()" qui sont plus des fonctions "multi-tâches" que les traditionnelles "GetMessage()","SendMessage()","PostMessage()" etc.

A+.
23/10/2006, 14h58
hal9000

merci, je vais voir çà
23/10/2006, 15h27
Shb33

Citation:

Envoyé par Médinoc

Un message posté avec PostThreadMessage() possède un HWND NULL.

Donc, le WM_CLOSE ou WM_DESTROY (ce dernier étant un hack, puis qu'il fait croire à la fenêtre qu'elle se détruit alors que ce n'est pas le cas) envoyé par PostThreadMessage() sera perdu par DispatchMessage() et la pompe à message du thread continuera. Seul WM_QUIT peut faire retourner 0 à GetMessage() et stopper ainsi la pompe.

Salut,
je débute dans l'api win32, et je ne comprends pas ce que tu dis.

Tu dis que c'est mal d'utiliser WM_DESTROY ? Pourtant, d'après ce que j'ai appris en cours c'est DestroyWindow qui est appelé par le système d'exploitation lorsque par exemple le système est eteint (WM_ENDSESSION). Et donc, si WM_CLOSE est un hack de WM_DESTROY (c'est quoi un hack, ca veut dire que c'est pareil ?) donc ca voudrait dire que WM_CLOSE est envoyé après reception de WM_ENDSESSION ? Donc c'est mal ce que fait le système d'exploitation quand on lui dit de s'éteindre ? pourquoi il n'envoie pas un message WM_QUIT a tous les threads alors ?

Est-ce que mon prof s'est trompé en nous expliquant ou est-ce que microsoft eux meme ne savent pas comment manipuler leurs fenetres ?
23/10/2006, 16h23
Médinoc
Ce que je disais était pour farscape.

Voilà ce que dit l'aide:

Citation:

Envoyé par MSDN: [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_close.asp]WM_CLOSE[/URL]

By default, the DefWindowProc function calls the DestroyWindow function to destroy the window.

Donc, si on envoie WM_CLOSE à une fenêtre, si elle n'intercepte pas WM_CLOSE, DestroyWindow() est automatiquement appelée sur la fenêtre --> Destruction de la fenêtre.
Donc:
- On peut traiter WM_CLOSE dans une procédure de fenêtre,
- On peut envoyer WM_CLOSE à une fenêtre.
Citation:

Envoyé par MSDN: [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/destroywindow.asp]DestroyWindow()[/URL]

The DestroyWindow function destroys the specified window. The function sends WM_DESTROY and WM_NCDESTROY messages to the window to deactivate it and remove the keyboard focus from it. The function also destroys the window's menu, flushes the thread message queue, destroys timers, removes clipboard ownership, and breaks the clipboard viewer chain (if the window is at the top of the viewer chain).
If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.

Donc, si on appelle DestroyWindow(), entre autres la fenêtre recevra un message WM_DESTROY. Mais ce n'est pas le message WM_DESTROY qui détruit la fenêtre!

Citation:

Envoyé par MSDN: [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_destroy.asp]WM_DESTROY[/URL]

The WM_DESTROY message is sent when a window is being destroyed. It is sent to the window procedure of the window being destroyed after the window is removed from the screen.
This message is sent first to the window being destroyed and then to the child windows (if any) as they are destroyed. During the processing of the message, it can be assumed that all child windows still exist.

Donc:
- On peut traiter WM_DESTROY dans une procédure de fenêtre,
- On ne doit pas envoyer WM_DESTROY à une fenêtre, puisque cela fait croire à une fenêtre qu'elle est en train d'être détruite alors que ce n'est pas le cas.
Je n'ai jamais travaillé avec WM_ENDSESSION, mais je suppose que oui, un message WM_CLOSE (ou même un message WM_QUIT) est reçu par la suite.
23/10/2006, 16h49
Shb33

merci pour ces explications, mais ce que je trouve bizarre, c'est que c'est marqué partout que le traitement par défaut de WM_CLOSE c'est d'appeler WM_QUIT.
Cela permet si j'ai bien compris de laisser l'occasion à l'application de se terminer proprement (sauvegarde et autres libérations de mémoire).
Si on envoie directement WM_QUIT cela ne laisse aucune chance au programme de se terminer correctement (s'il en a besoin), alors qu'en envoyant WM_CLOSE on lui laisse la possibilité de faire un traitement particulier (enventuellement).
Donc à moins que le programmeur soit tordu et empeche explicitement l'envoi de WM_QUIT, il est plus sur d'envoyer WM_CLOSE.

Est-ce que j'ai rien compris ?
23/10/2006, 17h07
Médinoc
Moi, je n'ai lu nulle part que "le traitement par défaut de WM_CLOSE c'est d'appeler WM_QUIT".

Par contre, le traitement souvent utilisé de WM_DESTROY pour la fenêtre principale est:
Code:

1 2 3 4 5 6 7 case WM_DESTROY: //Nettoyer //... //Terminer la boucle de messages PostQuitMessage(uneValeur); break;
Ainsi, une fois la fenêtre principale complètement détruite, la boucle de message tombera sur le WM_QUIT et se terminera.
23/10/2006, 17h26
Shb33

j'ai du me tromper alors ...
mais si WM_CLOSE entraine WM_DESTROY qui fait un PostQuitMessage, cela revient à ce que WM_CLOSE entraine WM_QUIT. C'est bien ca ?
Ce qui fait que pour laisser une chance à l'application de bien se terminer, il vaut mieux envoyer un WM_CLOSE, comme c'est marqué dans la note msdn.
C'est là où je ne comprends plus ... :?
23/10/2006, 17h48
farscape
Citation:

Envoyé par Shb33

j'ai du me tromper alors ...
mais si WM_CLOSE entraine WM_DESTROY qui fait un PostQuitMessage, cela revient à ce que WM_CLOSE entraine WM_QUIT. C'est bien ca ?
Ce qui fait que pour laisser une chance à l'application de bien se terminer, il vaut mieux envoyer un WM_CLOSE, comme c'est marqué dans la note msdn.
C'est là où je ne comprends plus ... :?

on discute on discute je commence a avoir du mal à suivre le fil de cette discussion, si tu envois un
Code:

1 2 PostMessage(hWnd,WM_CLOSE,0,0);
sur la fenêtre principal d'une application MFC elle se ferme bien .
:D
24/10/2006, 09h22
Shb33
Citation:
Envoyé par farscape

on discute on discute je commence a avoir du mal à suivre le fil de cette discussion, si tu envois un

Code:

1 2 PostMessage(hWnd,WM_CLOSE,0,0);

sur la fenêtre principal d'une application MFC elle se ferme bien .
:D
oui, excusez moi je m'égare
je crois que c'est effectivement ca le plus important.
D'envoyer le message WM_CLOSE à la fenetre principale, et si je me trompe pas, le message est diffusé en broadcast aux autres fenetres, celles qui sont filles de la fenetre principale. Et donc ca ferme tout

Merci à vous deux pour ces éclaircissement ;)
24/10/2006, 10h31
Denn's

Farscape,

tu fais comment pour retrouver le hWnd de la fenêtre principale de l'application B quand t'es dans l'application A ( Pour revenir à la question de départ ) ?:roll:
24/10/2006, 10h34
farscape

Citation:

Envoyé par Denn's

Farscape,

tu fais comment pour retrouver le hWnd de la fenêtre principale de l'application B quand t'es dans l'application A ( Pour revenir à la question de départ ) ?:roll:

salut,
avec un FindWindow du nom de l'application.
voir cet exemple:
http://farscape.developpez.com/Samples/KillProcess.zip
:D
24/10/2006, 11h33
Médinoc

Citation:

Envoyé par farscape

salut,
avec un FindWindow du nom de l'application.
voir cet exemple:
http://farscape.developpez.com/Samples/KillProcess.zip
:D

Le nom de l'application, ça ne veut rien dire. Il faut le nom que l'application donne à la fenêtre (en espérant que ce ne soit pas un éditeur de documents...).
24/10/2006, 11h47
farscape

Citation:

Envoyé par Médinoc

Le nom de l'application, ça ne veut rien dire. Il faut le nom que l'application donne à la fenêtre (en espérant que ce ne soit pas un éditeur de documents...).

t'en perds pas une toi, franchement tu crois que j'en suis la ?,
oui je me suis mal exprimé ,le titre de la fenêtre.