Discussion :

[GrandHunier]

Bonjour à tous,

J'ai un petit problème avec WinApi en C (OS: XP, éditeur: VC++ Express 2008) lors de l'utilisation d'une fenêtre que j'ai créée précédemment. lorsque la fenêtre a le focus de la souris, ou qu'il y a un rafraichissement de la partie de l'écran dans laquelle se trouve la fenêtre, le programme tourne bien, mais dès que le programme perd le focus, il semble se stopper. je ne sais pas trop d'où ça vient, la fenêtre est créée avec juste WS_SYSMENU | WS_MINIMIZEBOX, ce qui n'induit normalement pas de tel comportement. quelqu'un a-t-il une idée?
Je suis censé recevoir des trames TCP qui après modifient des boutons, mais les boutons ne sont pas modifiés (c'est pour cela que j'ai l'impression qu'il se bloque).

Si vous demandez le code source, je fournirai les parties importantes, mais si je peux appliquer les idées que l'on me donne directement, ce serait mieux pour me faire comprendre mon erreur.

Merci d'avance.

[bacelar]

Affichage graphique et réception de trame, cela implique très souvent du multi-threading.
Modifiez-vous bien les contrôles uniquement dans le thread ayant créé ces contrôles ?

[GrandHunier]

Le thread de réception des données effectue un changement sur une variable globale de contrôle, et le thread principal se charge, en fonction de l'état de la variable de contrôle, de modifier ce qui est nécessaire (comme je le disais, le boutons entre autres).
Il semble que le problème provienne du socket, quand je commente la partie concernant le socket et que je met à la place un timer avec changement d'état suivant ce timer, ça marche où que soit le focus. effectivement, ça viendrait de là donc, merci. avez-vous d'autres idées pour me dépanner?
Voici peut-être mon code pour le socket:

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
char reception[NOMBRE_CHAR_SOCKET];

int WINAPI WinMain(...)
{
	WSADATA wsaData;
	SOCKADDR_IN sin;
	u_long modeNonBloquant=0;//0:blocking, 1:non-blocking;
	reception[0] = '0';

	WSAStartup(MAKEWORD(1,0), &wsaData);
	sin.sin_addr.s_addr = inet_addr("172.16.30.25");
	sin.sin_family = AF_INET;
	sin.sin_port = htons(30000);
	sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	ioctlsocket(sock, FIONBIO, &modeNonBloquant);
	connect(sock, (SOCKADDR *)&sin, sizeof(sin));

	th = CreateThread(0, 0, ThreadTcp, NULL, 0, &idThread);

        while(1)
        {
                switch (reception[0])
		{
                case :
			InvalidateRect(fenetrePrincipale, NULL, TRUE);
			EnableWindow(btInhib, FALSE);
//je ne met qu'une partie des case afin de simplifier
                }
        }
}

[bacelar]

J'espère que votre code du thread graphique ne ressemble peu ou proue à celui que vous avez posté.

Pas de boucle active (while 1 {}) SVP.

Où est la Pompa à message (GetMessage) ?
http://msdn.microsoft.com/en-us/libr...36(VS.85).aspx

[GrandHunier]

Euh, si ..
Le DispatchMessage-TranslateMessage est dans le while(1), avant la réception par le socket. parce que je dois faire les deux en parallèle: envoi d'ordres par la fenêtre et étude de la réception TCP (qui doit agir après sur la fenêtre). mais il semble que ce ne soit pas bon... que faut-il faire alors?
D'après ce que vous dites, j'imagine qu'il faut threader pour paralléliser ce que je dois effectuer sans faire de boucle infinie, c'est ça? ou autre chose, je ne sais pas. je suis débutant en IHM avec WinApi.

[bacelar]

Je suis rassuré.

DispatchMessage implique un GetMessage.

Le problème, c'est que GetMessage bloque le thread graphique tant qu'il n'y a pas de message posté sur une des fenêtres.

Cela explique l'histoire du focus. Vous débloquez votre thread graphique lorsque le système de fenêtrage de Windows poste des messages pour la gestion de l'acquisition ou la perte du focus. Lors de ces postes, GetMessage retourne le message posté.

Il faut donc débloquer votre thread graphique quand il doit mettre à jour l'IHM.

Je vois deux moyens simples pour y arriver.

1- Soit vous postez depuis votre thread de réception des données, via la fonction PostMessage http://msdn.microsoft.com/en-us/libr...44(VS.85).aspx, par exemple sur la fenêtre principale de votre application, un message de type WM_APP (http://msdn.microsoft.com/en-us/libr...30(VS.85).aspx).
Vous pourrez même vous débarrassez de votre variable globale de contrôle, car les informations peuvent être transmise dans le message, sans risque de contention multi-thread dessus.

Si vous recevez beaucoup de données, il faudra peut-être trouver un moyen pour gérer le flux de message vers la fenêtre.

2- Vous pouvez utiliser un timer pour générer régulièrement un message WM_TIMER qui permettra à votre application de prendre en compte l'état de la variable globale de contrôle. Il permettra aussi d'éviter trop d'appel en cas de fort trafic.
http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx
http://msdn.microsoft.com/en-us/libr...02(VS.85).aspx