Discussion :

[bennnun]

Bonjour a tous,
Je viens quemander votre aide au sujet d'un probleme que je viens de rencontrer en utilisant la fonction PostThreadMessage.
J'ai deux applications que je fais communiquer en utilisant des messages.
Actuellement, j'ai le code suivant et cela marche :

Code :

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

1
2
3
4
5
6
7
8
 
unsigned int uiValue = 13;
double dValue = 25.3;
CWnd* pWnd = NULL; 
pWnd = FindWindow(NULL, _T("MyApp"));
 
if (pWnd)    
     PostThreadMessage(GetWindowThreadProcessId(pWnd->GetSafeHwnd(), NULL), WM_UPDATE_PARAMETER, uiValue, (LPARAM)dValue);

Dans l'application "MyApp", je recois correctement le message.
Maintenant, j'aimerais changer cette facon de faire car le nom de l'application peut changer. Hors comme le nom de l'executable est toujours le meme, j'ai essaye le code suivant :

Code :

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

1
2
3
 
DWORD dwProcessID = dwGetProcessID(_T("MyApp.exe"));
PostThreadMessage(dwProcessID, WM_UPDATE_PARAMETER, uiValue, (LPARAM)dValue);

Lorsque je regarde l'erreur avec GetLastError(), j'ai

1444 = ERROR_INVALID_THREAD_ID...

Note :
La fonction "dwGetProcessID()" est definit comme ceci :

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
 
#include "Tlhelp32.h"
 
DWORD dwGetProcessID(CString csProcessName)
{
	HANDLE hndl = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
	DWORD dwsma = GetLastError();
	DWORD dwExitCode = 0;
	PROCESSENTRY32  procEntry = {0};
	procEntry.dwSize = sizeof(PROCESSENTRY32);
	Process32First(hndl, &procEntry);
	BOOL bSWFound = FALSE;
 
	// Look for the control SW in the list of processes
	do
	{
		if (!_wcsicmp(procEntry.szExeFile, csProcessName))
		{
			bSWFound = TRUE;
			break;
		}
	}
	while(Process32Next(hndl, &procEntry));
 
	if (bSWFound == TRUE)
		return procEntry.th32ProcessID;
	else
		return 0;
}

Je ne comprends pas pourquoi dans un cas, cela fonctionne et dans l'autre non...
Merci d'avance.

[bacelar]

Tant de code sans traitement des codes de retour, et qui marche pas, c'est étonnant ?

Primo : Commencez par gérer les codes de retour, cela permet de ne pas chercher inutilement.

Secondo : Doc MSDN

idThread
[in] Identifier of the thread to which the message is to be posted.
The function fails if the specified thread does not have a message queue. The system creates a thread's message queue when the thread makes its first call to one of the User or GDI functions. For more information, see the Remarks section.

Microsoft Windows Vista and later.Message posting is subject to User Interface Privilege Isolation (UIPI). The thread of a process can post messages only to posted-message queues of threads in processes of lesser or equal integrity level.

Windows 2000/XP: This thread must either belong to the same desktop as the calling thread or to a process with the same locally unique identifier (LUID). Otherwise, the function fails and returns ERROR_INVALID_THREAD_ID.

Windows Server 2003 SP1: This thread must have the SE_TCB_NAME privilege to post a message to a thread that belongs to a process with the same locally unique identifier (LUID) but is in a different desktop. Otherwise, the function fails and returns ERROR_INVALID_THREAD_ID.

Tercio: l'envoie de message c'est bien le mode de communication entre processus le plus pourri de tous, et de très très loin.

[bennnun]

Merci de votre reponse.
Tout d'abord, desole, je pense que j'ai homis des informations.
Je viens d'editer mon poste pour les erreurs de code.
Pour le premier point, afin que le post soit concis, j'ai deliberemment modifier le code pour qu'il soit le plus court possible. La gestion des erreurs, je l'ai faite par le debuggeur. J'ai notamment regarde le process ID retourne et le BOOL retourne par PostThreadMessage.
Pour le second point, j'ai lu la documentation de la MSDN relative a PostThreadMessage, a la definition des process Id et de leurs contextes. Mes deux applications tournent sur le meme ordinateurs et j'ai le debuggeur sur les deux (sur un poste avec windows XP). Du messages d'erreur, j'en ai retire de la doc que deux problemes pouvaient se poser, soit le process etait invalide, soit la message queue non existante. Au vu du premier code que j'ai precedemment poste, le process Id etait correct vu que le message transite correctement par le HWND, et cela me conforte dans la croyance que mes messages queues existent bien (d'autant plus que nombres de messages sont echanges et j'ai pu verifier le bon fonctionnement de cet echange).
C'est le simple fait d'echanger la facon d'envoyer le message a travers le process Id qui me pose probleme.
Pour le troisieme point, j'avais un client a cote de moi qui ne parle pas ma langue, avec qui j'echangais dans un anglais approximatif, qui avait un debut de grippe et qui voulait juste voir que la connexion entre les logiciels etaient operationnelles comme dit "officiellement" par mon entreprise, le tout dans une fraiche ambiance d'annulation de ma semaine de vacances. Un echange par message m'a semble le plus rapide a ce moment la pour repondre a son besoin. Oui je me defends d'avoir choisi cette methode qui je dois l'admettre "marche", mais qui ne me sieds pas plus qu'enfiler des pantoufles faites en poils de Yak (et j'ai beaucoup d'estime pour cet animal). Moins serieusement, j'ai ma fierte . Maintenant dire "c'est pourri" a plus d'impact lorsque cela est argumente.
Merci de votre reponse et j'espere que vous avez plus d'information desormais pour continuer a m'aider si le coeur vous en dit bien evidemment.

PS : Desole pour les fautes d'accent, clavier japonais....

[bacelar]

Pouvez-vous comparez les résultats entre "dwGetProcessID" et "GetWindowThreadProcessId(pWnd->GetSafeHwnd(), NULL".
S'ils sont identiques, on est un peu dans la m****.

Mais je pense fortement que non. Utilisez Spy++ pour voir avec quel processus dwGetProcessID dialogue.

Heu, je viens de remarquer : "th32ProcessID" C'est l'identifiant du processpas du thread.

Maintenant dire "c'est pourri" a plus d'impact lorsque cela est argumente.

Je ne connais aucune autre IPC qui est fonction d'une chose aussi volatile que le titre d'une fenêtre ou le nom d'un exécutable. Que ça soit les pipes, les mailslot, les sockets, la mémoire partage, les files MSMQ, des Web Services du .NET Remoting, un middleware Corba, un ESB d'orchestration etc...
Oui, j'ai bien dit aucun.
Il y aurait bien DDE d’aussi pourri, mais c’est vraiment limite.

[bennnun]

Merci pour votre reponse !
Effectivement, il y avait confusion entre le process ID et le thread ID...
J'ai remplace la fonction dwProcessID() par la suivante :

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
 
DWORD dwGetThreadID(CString csProcessName)
{
    HANDLE hndlProcess = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    HANDLE hndlThread = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
 
    if (hndlProcess != 0)
    {
        PROCESSENTRY32  procEntry = {0};
	procEntry.dwSize = sizeof(PROCESSENTRY32);
	Process32First(hndlProcess, &procEntry);
	BOOL bSWFound = FALSE;
 
	// Look for the control SW in the list of processes
	do
	{
	    if (!_wcsicmp(procEntry.szExeFile, csProcessName))
	    {
		bSWFound = TRUE;
		break;
	    }
	}
	while(Process32Next(hndlProcess, &procEntry));
 
	if (bSWFound == TRUE)
	{
	    THREADENTRY32 te32 = {0};
	    te32.dwSize = sizeof(THREADENTRY32);
 
	    if ((hndlThread != 0) && (Thread32First(hndlThread, &te32))
	    {
                // As soon as we found one, we return its thread ID
                // Note : Work for single thread...
	        do
		{
		    if (te32.th32OwnerProcessID == procEntry.th32ProcessID)
		        return te32.th32ThreadID;
		}
		while(Thread32Next(hndlThread, &te32));
	    }
 
	    return 0;
	}
	else
	    return 0;
    }
    else
	return 0;
}

Et maintenant le PostThreadMessage fonctionne correctement.
A noter que la fonction precedente renvoie l'ID de la premiere thread trouve. Elle ne sera donc d'aucune utilite dans le cas ou l'on souhaite dialoguer dans un environnement multithread.
Merci encore pour les indices Bacelar.

Pour ce qui est des messages, je suis en accord de principe avec vous, seulement les situations ne sont pas toujours en notre faveur. Quand un integrateur/client ne connait que les messages, et qu'il a travaillait avec pendant des annees, il rechigne a changer sa facon de faire.
Tout est une histoire de compromis du coup .