[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