[MFC] PostMessage depuis Thread vers CDialog

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour � tous,

je vous explique mon petit souci : j'ai une bo�te de dialogue CDialog � partir de laquelle je lance un Thread de Travail en cliquant sur un bouton.
De ce c�t�-l�, tout va bien, j'ai fait une m�thode LRESULT, j'ai ajout� ON_MESSAGE dans le message map, j'ai d�fini un message windows WM_APP+1.

Quand je lance mon Thread, j'aimerais utiliser une classe C++ que j'ai faite.

Le probl�me est comment j'utilise PostMessage pour envoyer des infos concernant la mise � jour des contr�les visuels (barre de progression...).

En effet, quand je met le code de ma classe directement dans le thread, �a marche parce que le message WM_APP+1 est d�fini dans la classe CDialog.

Mais si je cr�e une instance de ma classe dans le thread, alors je n'ai plus acc�s au message WM_APP+1 car il est priv�.

Un petit bout de code juste histoire de :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 // CDialog.cpp #include "CDialog.h" #include "FEMU.h" #define WM_MESSAGE WM_APP+1 static UINT Thread(void *pParam) { FEMU test(pParam); // instance de ma classe FEMU dans le thread return 0; } // FEMU.cpp FEMU::FEMU(void *pParam) { PostMessage(???) }
J'esp�re avoir �t� clair. Merci d'avance pour votre aide.

06/02/2017, 16h14
bacelar

C'est quel PostMessage que vous voulez utiliser ???

https://msdn.microsoft.com/fr-fr/library/9tdesxec.aspx

https://msdn.microsoft.com/fr-fr/lib...(v=vs.85).aspx

Citation:

alors je n'ai plus acc�s au message WM_APP+1 car il est priv�

What, c'est une MACRO, les probl�mes majeurs des MACRO, c'est que tout le monde(n'importe quel code) peut s'en servir et que le typage est � la rue.

Je ne vois pas trop la difficult�, dans le constructeur de votre thread, vous passez tous les param�tres dont il a besoin pour faire son job.

Donner les param�tres au thread, ce n'est pas un probl�me. C'est surtout comment les r�cup�rer une fois dans ma classe C++ (qui ne d�rive pas d'une CDialog).

Voici un exemple de base pour illustrer :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
void CDialog::OnBnClickedCalcul()
{
	ThreadInfos *pThreadInfos = new ThreadInfos;               // ThreadInfos est une structure globale (je sais que ce n'est pas bien :aie:)
	pThreadInfos->hWnd = m_hWnd;
	pThread = AfxBeginThread(ThreadCalcul, pThreadInfos, THREAD_PRIORITY_NORMAL, 0, 0);
}
 
static UINT ThreadCalcul(void *pParam)
{	
	ThreadInfos *pThreadInfos = (ThreadInfos*)pParam;
	for (int i = 0; i < 100; i++){
		Sleep(100);
		pThreadInfos->itr = i + 1;
		PostMessage(pThreadInfos->hWnd, WM_THREAD_MESSAGE, reinterpret_cast<WPARAM>(pThreadInfos), 0);
	}
	delete pThreadInfos;
	return 0;
}

Cela fonctionne tr�s bien, mais si maintenant j'utilise ma classe FEMU (dans laquelle j'ai des calculs � faire) :

Code:

1
2
3
4
5
6
7
8
 
static UINT ThreadCalcul(void *pParam)
{	
	ThreadInfos *pThreadInfos = (ThreadInfos*)pParam;
	FEMU test(pThreadInfos);
	delete pThreadInfos;
	return 0;
}

Il se trouve alors que je n'ai acc�s � rien :

Code:

1
2
3
4
5
6
7
8
9
 
FEMU::FEMU(void *ptr)
{
       	for (int i = 0; i < 100; i++){
		Sleep(100);
		ptr->itr = i + 1;            // Impossible d'utiliser ptr
		PostMessage(pThreadInfos->hWnd, WM_THREAD_MESSAGE, reinterpret_cast<WPARAM>(ptr), 0);     // Impossible d'utiliser WM_THREAD_MESSAGE
	}
}

Je sais que la solution n'est pas loin mais je ne vois pas quoi faire.

07/02/2017, 08h49
M�dinoc

Code:

FEMU::FEMU(ThreadInfos *ptr)
07/02/2017, 10h34
js_naka
J'ai essay�, �a ne fonctionne pas non plus. Il me dit que ThreadInfos n'est pas d�fini. Ce qui me para�t normal car cette structure globale est d�finie dans CDialog.cpp. Ma classe FEMU est d�finie dans les fichiers FEMU.h et FEMU.cpp.

J'ai essay� aussi de faire �a dans FEMU.h :
Code:

1 2 3 4 5 6 7 8 class CDialog; class FEMU { public: FEMU(ThreadInfos *ptr); ~FEMU(); }
mais �a ne change rien.

et ceci?

Code:

1
2
3
4
5
6
7
8
9
class CDialog;
class ThreadInfos;
 
class FEMU
{
public:
     FEMU(ThreadInfos *ptr);
     ~FEMU();
};

07/02/2017, 15h21
js_naka

En lisant ta r�ponse, je me suis dit : "Mais oui bien s�r que c'est �a !".

Et en l'appliquant, toujours la m�me erreur : "pointeur vers un type classe incompl�te non autoris�".

Je ne comprends pas...
07/02/2017, 15h55
bacelar

Code:

PostMessage(pThreadInfos->hWnd, WM_THREAD_MESSAGE, reinterpret_cast<WPARAM>(pThreadInfos), 0);

Pas le "WPARAM" pour un pointeur, SVP. 8O
https://blogs.msdn.microsoft.com/old...5-00/?p=41713/

Code:

delete pThreadInfos;

Deleter un pointeur que vous avez pass� en param�tre d'un message, l�, c'est des emmerdes assur�s.
L'utilisation shared_ptr et une gestion du cycle de vie des objets de type "ThreadInfos" s'impose.

Citation:

Je ne comprends pas...

Heu, l�, c'est quand m�me le b.a.-ba du C++, les classes.

"ThreadInfos" est une classe comme une autre. Cr�ez un .h et un .cpp (si n�cessaire) contenant respectivement la d�claration et l'impl�mentation de cette classe.
Comme est sera utilis�e par 2 classes diff�rentes : "CDialog" et "FEMU", il faut la mettre dans un ensemble de fichiers (.h .cpp) distinct.
Dans les .cpp de ces 2 classes, vous ajoutez un

Code:

#include "ThreadInfos.h"

o� il faut.
07/02/2017, 16h44
js_naka

Ok, je vais regarder �a ce soir.

Citation:

Envoy� par bacelar

Code:

PostMessage(pThreadInfos->hWnd, WM_THREAD_MESSAGE, reinterpret_cast<WPARAM>(pThreadInfos), 0);

Pas le "WPARAM" pour un pointeur, SVP. 8O
https://blogs.msdn.microsoft.com/old...5-00/?p=41713/

�a, en th�orie �a n'a jamais �t� un probl�me (vu que sous Win16 un pointeur "normal" aurait �t� court de toute fa�on) et en pratique �a n'a �t� un probl�me que pour Windows 9x dans le cas pr�cis de SendMessageTimeout(). �a n'est clairement pas un probl�me de nos jours, o� WPARAM et LPARAM sont des UINT_PTR et LONG_PTR respectivement.

Citation:

Code:

delete pThreadInfos;

Deleter un pointeur que vous avez pass� en param�tre d'un message, l�, c'est des emmerdes assur�s.
L'utilisation shared_ptr et une gestion du cycle de vie des objets de type "ThreadInfos" s'impose.

Au contraire, c'est la pratique courante pour une communication inter-thread � sens unique: Allouer dans le thread appelant, passer � la fonction de cr�ation de thread, et "oublier" (du pur "fire-and-forget"), et lib�rer dans le thread destinataire. Il y a donc un transfert de responsabilit� qui doit se faire hors d'un pointeur intelligent parce que la fonction de cr�ation de thread n'accepte qu'un pointeur b�te.

Par contre, on pourrait quand m�me avoir un pointeur intelligent de chaque c�t�:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 UINT __cdecl ThreadProc(void* ptr) //AFX_THREADPROC has different requirement from LPTHREAD_START_ROUTINE { unique_ptr<ThreadInfos> spInfos(static_cast<ThreadInfos*>(ptr)); FEMU femu(spInfos); return 0; } ... { unique_ptr<ThreadInfos> spInfos = make_unique<ThreadInfos>(); spInfos->hWnd = pDlg->hWnd; AfxBeginThread(ThreadProc, spInfos.release()); }
Citation:

Heu, l�, c'est quand m�me le b.a.-ba du C++, les classes.

"ThreadInfos" est une classe comme une autre. Cr�ez un .h et un .cpp (si n�cessaire) contenant respectivement la d�claration et l'impl�mentation de cette classe.
Comme est sera utilis�e par 2 classes diff�rentes : "CDialog" et "FEMU", il faut la mettre dans un ensemble de fichiers (.h .cpp) distinct.
Dans les .cpp de ces 2 classes, vous ajoutez un

Code:

#include "ThreadInfos.h"

o� il faut.

L�, je suis d'accord.

Merci � vous deux de perdre un peu de temps avec mon cas.

Bon, j'ai essay� de faire ce que vous me conseillez. Effectivement, maintenant j'ai acc�s aux infos mais si on revient � la question initiale, le message � poster est toujours non d�fini.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include "FEMU.h" #include "ThreadInfos.h" FEMU::FEMU(void *pThreadInfos) { ThreadInfos *ptr = (ThreadInfos*)pThreadInfos; for (int i = 0; i < 100; i++){ Sleep(100); ptr->itr = i + 1; PostMessage(ptr->hWnd, WM_MESSAGE, reinterpret_cast<WPARAM>(ptr), 0); // WM_MESSAGE inconnu } }
WM_MESSAGE est d�fini dans CDialog.cpp. Du coup, dois-je le passer � la classe ThreadInfos ou au contraire en cr�er un nouveau pour l'envoyer au CDialog ?

08/02/2017, 08h27
M�dinoc

Rajoute-le dans ThreadInfos pour plus de souplesse et pour �viter de dupliquer la valeur.
08/02/2017, 23h21
js_naka

Bon, �a ne marche toujours pas. J'ai essay� plein de choses mais il y a toujours un truc qui manque ou qui n'est pas reconnu. Je perds beaucoup de temps l�-dessus parce que je ne ma�trise pas le langage.

Du coup, toutes mes classes, je vais les mettre directement dans le CDialog.cpp. C'est pr�cis�ment ce que je voulais �viter mais je ne suis pas capable de faire autrement donc tant pis.

Merci � vous deux quand m�me pour m'avoir aid�.
09/02/2017, 11h22
bacelar

Vous bloquez juste sur le fait de faire un .h et un .cpp par classe ??? :weird:

Bon je m'y suis remis et j'ai r�ussi. Les erreurs venaient de plusieurs choses :

- je passais l'adresse du pointeur de la classe ThreadInfos au thread au lieu de passer le pointeur lui-m�me ;
- le message �galement n'�tait pas bon.

Bref, plein de conneries.

En fait, c'est hyper simple. Maintenant que je viens de le faire, je comprends exactement la logique du 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
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
 
// CDialog.cpp
 
#define WM_THREAD_MESSAGE		WM_APP+1
 
ON_MESSAGE(WM_THREAD_MESSAGE, &CIdMDICx64Dlg::ThreadMessage)
 
LRESULT CDialog::ThreadMessage(WPARAM wParam, LPARAM)
{
	ThreadInfos *pThreadInfos = (ThreadInfos*)wParam;
	barre_progression.SetPos(pThreadInfos->itr);
	pThreadInfos->str.Format(_T("Processus : %d"), pThreadInfos->itr);
	affich_processus.SetWindowText(pThreadInfos->str);
	return 0;
}
 
void CDialog::OnBnClickedCalcul()
{
	pThreadInfos = new ThreadInfos;       // pThreadInfos est membre de CDialog
	pThreadInfos->hWnd = m_hWnd;
        pThreadInfos->Message = WM_THREAD_MESSAGE;
	pThread = AfxBeginThread(ThreadCalcul, pThreadInfos, THREAD_PRIORITY_NORMAL, 0, 0);
}
 
static UINT ThreadCalcul(void *pParam)
{	
	ThreadInfos *pThreadInfos = (ThreadInfos*)pParam;
	FEMU test(pThreadInfos);
	return 0;
}
 
// FEMU.cpp
FEMU::FEMU(ThreadInfos *ptr)
{
	ThreadInfos *pThread = (ThreadInfos*)ptr;
	for (int i = 0; i < 100; i++){
		Sleep(100);
		pThread->itr = i + 1;
		PostMessage(pThread->hWnd, pThread->Message, reinterpret_cast<WPARAM>(pThread), 0);
	}
}
 
// ThreadInfos.h
class ThreadInfos
{
public:
	ThreadInfos();
	~ThreadInfos();
	HWND hWnd;
	int itr;
	UINT Message;
	CString str;
};

Merci encore pour votre aide.

09/02/2017, 18h45
M�dinoc

Attention, tu oublies de d�truire l'objet � la fin de ton traitement. Mais attention, PostMessage() �tant asynchrone, le seul moyen qu'il te reste pour d�truire l'objet est de le faire d�truire par le thread principal, une fois qu'il re�oit un message lui disant que le traitement est termin�...

PS: Pourquoi fais-tu ce traitement dans un constructeur?

Oui, effectivement j'ai oubli� de mettre cette partie du code. En fait, je le supprime en fermant la dialogue ou en recommen�ant le thread :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // CDialog.cpp void CDialog::OnBnClickedCalcul() { if (pThreadInfos != NULL) { delete pThreadInfos; pThreadInfos = NULL; } pThreadInfos = new ThreadInfos; // pThreadInfos est membre de CDialog pThreadInfos->hWnd = m_hWnd; pThreadInfos->Message = WM_THREAD_MESSAGE; pThread = AfxBeginThread(ThreadCalcul, pThreadInfos, THREAD_PRIORITY_NORMAL, 0, 0); } void CDialog::OnClose() { if (pThreadInfos != NULL) { delete pThreadInfos; pThreadInfos = NULL; } CDialogEx::OnClose(); }
Je ne sais pas si c'est la bonne m�thode par contre.

Concernant le traitement dans le constructeur, je l'ai mis comme �a, je n'ai pas r�fl�chi. La difficult� pour moi, c'�tait d'utiliser une classe dans un thread tout en envoyant des infos � la dialogue. Maintenant, je vais changer pour impl�menter vraiment toutes les m�thodes de ma classe et poster les messages � partir des ces m�thodes.

10/02/2017, 11h13
bacelar

Ta gestion du cycle de vie de "pThreadInfos" est acrobatique et complexe (et non safe).
Le plus simple, c'est de ne pas en faire un champ et de suivre le conseil de @M�dinoc.
10/02/2017, 11h57
js_naka

Ok, je vais faire le n�cessaire.

Merci pour les conseils
10/02/2017, 14h07
js_naka

Je vais encore vous emb�ter un petit peu...

Au lieu d'envoyer un message pour d�truire pThreadInfos comme vous le sugg�rez, n'est-il pas plus simple d'utiliser un CEvent ?

Voir 40 message(s) de cette discussion en une page