Discussion :

[Gruik]

[edit : le vrai probleme est expliqué dans mon 2eme message.
Merci de votre comprehension]

Salut, je cherchais simplement a changer le texte d'un Label mais pour des raisons que j'ennoncerai ptet plus tard, j'ai pas voulu utiliser SetDlgItemText ou SendMessage, mais plutot PostMessage avec WM_SETTEXT :

Code :

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

PostMessage (hMonLabel, WM_SETTEXT, 0, (LPARAM)"Coucou");

où hMonLabel est un HWND renvoyé par GetDlgItem.

Et bein ca marche pas :
- le label est inchangé
- PostMessage renvoie 0

[Aurelien.Regat-Barrel]

La doc dit :

If you send a message in the range below WM_USER to the asynchronous message functions (PostMessage, SendNotifyMessage, and SendMessageCallback), its message parameters cannot include pointers. Otherwise, the operation will fail. The functions will return before the receiving thread has had a chance to process the message and the sender will free the memory before it is used.

Cela dit, je comprends pas trop le probleme dans ton cas.

[Gruik]

Ah oki
Et comment savoir qu'un message est "en dessous de" WM_USER ?

Bon en fait, mon vrai probleme, c encore un pb de multi-threading..
Le thread que je crée met a jour des Labels dans ma fenetre (et aussi une progressbar) et.. je veux que qd je clique sur le bouton Stop, ca stoppe le thread.
Pour ca g utilisé une variable globale qui est testée dans la boucle de mon thread et que je positionne a une certaine valeur, dans la procedure de gestion de fenetre, dès interception du click sur "Stop".

Cependant, pour pas qu'il yait de probleme, j'ai voulu "synchroniser" l'arret du thread, et ca par l'appel de WaitForSingleObject().
Le pb, c que j'ai du placer cette instruction, a l'interieur de la procedure de la fenetre, juste apres l'affectation de ma variable globale d'arret. ca bloque la procedure de la fenetre (donc le thread principal) au niveau de cette instruction d'attente...
La où je comprenais pas, c que mon thread ne s'arretait jamais.. (où uniquement par timeout).

Apres reflexion, j'ai conclu que ca pouvait etre les SetDlgItemText() se trouvant dans la boucle de mon thread qui mettaient le binz.
CAR, les SetDlgItemText() sont vraissemblablement equivalents à des SendMessage() de WM_SETTEXT, et SendMessage attend que le message soit bien intercepté pour retourner.
OR, ma procedure de gestion des messages est bloquée par le WaitForSingleObject.......
J'ai lu que PostMessage() n'attendait pas que le message soit intercepté pour retourner donc j'ai voulu essayer ca. Mais ca marche pas.

Ainsi, que dois je faire :
Au pire je peux toujours "killer" le thread avec TerminateThread(), mais dans le tuto c expliqué que c un peu chacal de faire ca. Ou bien ne pas du tout attendre la fin du thread..

Merci pour votre patience.

[Walm]

Salutation,
as tu mis:

Code :

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

#define UM_TOTO           (WM_APP + 123)

par exemple?
Cordialement
Walm

[Gruik]

Salut,

Non, j'avais pas créé de Message Perso...



Bon finalement j'ai trouvé une solution : tester systematiquement ma variable globale d'état avant d'appeller tout SendMessage... Comme ca ya pas de bloquage, qd on appuye sur stop.

Merci.

[Gruik]

Hm, j'ai trouvé une autre solution.. un peu plus propre.

J'ai créé ce message perso :

Code :

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

#define UM_CAN_BE_ENDED WM_USER + 33

.. qui en fait sera envoyé a la fenetre par le thread créé pour indiquer qu'il compte plus envoyer de Messages (on pourra donc appeller WaitForSingleObject() en toute tranquilité).

G cette variable globale qui permettra de stopper le thread :

Code :

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

enum ThState {STOP, RUNNING, STOPPING} etat;

Positionnée à STOP au debut du programme
Positionnée à RUNNING juste avant l'appel de CreateThread
Positionnée à STOPPING des interception du click sur le bouton Stop (par exemple)
Repositionnée à STOP apres le WaitForSingleObject()

Dans la fonction de mon thread, j'aurais un code genre :

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
DWORD WINAPI threadProc (LPVOID lpParam)
{
	//...
	//...

	while (/*condition(s) && */ etat == RUNNING)
	{
		//Traitement
		//... avec ventuellement des SendMessage
		//...
	}

	//Envoi du message perso à la fenetre principale pour dire qu'elle peut s'attendre à la fin du thread.
	PostMessage (hDlg, UM_CAN_BE_ENDED, 0, 0);

	//.. instructions finales (mais pas de SendMessage!)
	return 0;
}

Et dans le swith (message) de ma fonction de fenetre j'aurais :

Code :

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

1
2
3
4
5
case UM_CAN_BE_ENDED :
	WaitForSingleObject(hThread, 2000);
	etat = STOP;
	//autres instructions
	return TRUE;

[Aurelien.Regat-Barrel]

As-tu pensé à une boucle PeekMessage à la place d'une boucle GetMessage. Si chaque itération de ta boucle while(condition) est courte (qq dizaines voire centième de secondes max), ça peut être bien, plus besoin de thread :

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
while ( TRUE )
{
    // s'il y a un message
    if ( PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE) )
    {
        // le traiter
        if ( GetMessage( &msg, NULL, 0, 0 ) )
        {
            TranslateMessage( &msg );
            DispatchMessage( &msg );
        }
        else
        {
            // WM_QUIT
            break;
        }
    }
    else
    {
        // sinon effectuer le traitement
        Traitement();
    }
}

[Gruik]

Ouais, j'éssairai la prochaine fois ,)