Tâche en continu dans une appli WIN32

Bonjour,

Je suis en train de m'initier à la programmation d'une application Win32 en langage C. Voilà le fonctionnement de la partie qui me pose problème:

Lorsque l'utilisateur clique sur un bouton, je pilote une sonde brancher sur l'USB qui envoie une commande et récupère une donnée. En fonctionnement standard, un clic de l'utilisateur ça fonctionnement ça problème.

Je voudrais faire un autre bouton qui active une fonctionnement SCAN, cad que j'émets la commande et reçois en continue la donnée avc mise à jour de la donnée dans un Edit.

Et c'est cette partie que je ne sais pas gérer, je ne sais pas où positionner mon code pour que ça n'empêche pas de prendre en compte un clic de l'utilisateur pour stopper le scan. Si je le positionne dans le "case" des messages reçus par la fenêtre, ma donnée se met à jour uniquement quand ma fenêtre à le focus (souris devant la fenêtre). Je foudrais qu'elle cela fonctionne même si je clique sur un autre programme du même genre qu'une tâche de fond.

Je ne sais pas si vous allez comprendre mon problème, mais merci d'avance


@mitié d'internaute
FRED

Bonjour Bruno et merci de ta réponse,
tu peux m'aiguiller vers un exemple ou un tutoriel qui explique un peu l'utilisation des threads, je suis un novice en la matière.

Le principe du timer en détail c'est peut être plus simple, ça donne quoi dans les grandes lignes ?

merci encore

Ah oui, oups...
Merci de la précision.

@+
Buno
----------------------------------------
L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai...

Les Event sont également très pratiques dans ce genre de situation.
Je te donne un morceau de code d'un de mes progs, le thread primaire fait tourner en simultané plusieurs threads auxiliaires.

typedef struct _CPRSSAUX {
LPBNCMPRSS pCMPRS; // +0
HANDLE hevParent; // +8
HANDLE hevWait; // +16
HANDLE hthrd; // +24
BYTE bEnd; // +32
BYTE err; // +33, 1 LECTURE, 2 COMPRESSION
BYTE work; // +34, 1 doit compresser, 0 rien
BYTE dummy[5]; // +35
} CPRSSAUX, *LPCPRSSAUX; // sizeof = 40

DWORD WINAPI CmprsAux(LPVOID pprm)
{
LPCPRSSAUX paux = (LPCPRSSAUX) pprm;
nextDataProc:
WaitForSingleObject(paux->hevWait, INFINITE);
paux->err = 0;
ResetEvent(paux->hevWait);
if(paux->bEnd) goto notifPARENT;
if(!paux->work) goto notifPARENT;
paux->err = (BYTE) bnCompressEx(paux->pCMPRS);
notifPARENT:
SetEvent(paux->hevParent);
if(!paux->bEnd) goto nextDataProc;
return 0;
}

Dans la fonction de thread, on voit que le thread ne fera jamais de boucle éternelle. A chaque tour il notifie le parent de l'état de son travail et ne se remet en position de départ que si le parnet l'indique, sinon il sort proprement.
Les boucles éternelles utilisent inutilement les CPUs, c'est à éviter comme la peste.

ciao...
BruNews, MVP VC++

Oui tout à fait BruNews. J'ai évité de parler de l'utilisation des Events et autres objets Windows pour ne pas charger le post. Personnellement, je préfère utiliser des boucles de messages dans les threads. Ceci permet une communication parfaite avec le thread primaire. Chaque thread sait où en est arrivé l'autre et agit en conséquence en échangeant des messages personnalisés. Je trouve même que c'est plus direct. Ainsi, le thread peut exécuter différentes tâches selon le message reçu et informe son appelant du résultat du traitement. Quelques appels PostThreadMessage() remplaceraient avantageusement les CreateEvent(), SetEvent(), ResetEvent() et WaitForSingleObject(). Enfin c'est ce que je pense à moins qu'il y ait une vraie raison de toujours préférer ces fonctions pour la communication entre threads.
Les boucles infinies bouffent le temps CPU si elles ne contiennent pas de fonction bloquante. Mais parfois on est obligé d'utiliser ces boucles pour finir un certain traitement le plus vite possible même en chargeant à fond les CPUs.