communication entre 2 applications (exe)

**hal9000** · 18/10/2006, 13h57

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 :

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

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...

**Médinoc** · 18/10/2006, 13h59

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

**farscape** · 18/10/2006, 14h21

voir déjà la faq:
http://c.developpez.com/faq/vc/?page...ad#ProcessKill

**hal9000** · 18/10/2006, 14h30

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.

**farscape** · 18/10/2006, 14h43

alors tu as ta reponse dans la faq...

**Médinoc** · 18/10/2006, 16h06

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...

**farscape** · 18/10/2006, 16h12

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&

**Médinoc** · 19/10/2006, 09h52

Envoyé par Microsoft KB

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

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...

**farscape** · 19/10/2006, 12h02

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 :

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

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;
}

**Médinoc** · 19/10/2006, 12h12

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

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.

**hal9000** · 23/10/2006, 13h23

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 :

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

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 :

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

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)

**farscape** · 23/10/2006, 14h03

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.

**Médinoc** · 23/10/2006, 14h08

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.

**hal9000** · 23/10/2006, 14h17

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...

**Denn's** · 23/10/2006, 14h46

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+.

**hal9000** · 23/10/2006, 14h58

merci, je vais voir çà

**Shb33** · 23/10/2006, 15h27

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 ?

**Médinoc** · 23/10/2006, 16h23

Ce que je disais était pour farscape.

Voilà ce que dit l'aide:

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.

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!

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.

**Shb33** · 23/10/2006, 16h49

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 ?

**Médinoc** · 23/10/2006, 17h07

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 :

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

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.

communication entre 2 applications (exe)

MFC

Discussions similaires

Partager

Partager