cs_talonneur
Messages postés8Date d'inscriptionmardi 17 février 2004StatutMembreDernière intervention22 février 2013
-
17 nov. 2010 à 16:15
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 2014
-
18 nov. 2010 à 15:50
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
BunoCS
Messages postés15475Date d'inscriptionlundi 11 juillet 2005StatutModérateurDernière intervention23 avril 2024103 17 nov. 2010 à 16:23
Hello,
Il te faut lancer un thread dédié à la récupération des messages de ta sonde:
- dès qu'une donnée est reçue, ton thread envoie un message (SendMessage) à ta fenêtre principale pour maj
- dès que le user clique sur le bouton stop, ça envoie un message à ton thread qui arrête de récupérer des infos
Ou bien, tu passes par un timer qui va vérifier les données à chaque "tick"
@+
Buno
----------------------------------------
L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai...
BunoCS
Messages postés15475Date d'inscriptionlundi 11 juillet 2005StatutModérateurDernière intervention23 avril 2024103 17 nov. 2010 à 16:58
Tu isoles dans une fonction la récupération des données depuis le scan.
Dans le cas du thread, cette fonction contient quelque chose te permettant de boucler à l'infini. Par exemple
while (1)
{
...
}
Tu crée le thread via CreateThread() A l'appui sur le bouton Stop, il suffit de killer le thread (voir CloseHandle()).
Pour le timer, en début de prog, tu fais un SetTimer(). Dans ta boucle de message, tu capture le message WM_TIMER via le switch et tu peux appeler ta fonction de récup de données. Sur l'action d'appui sur Stop, tu fais un KillTimer()
Tu devrais pouvoir trouver des exemples bien fait sur ce site.
@+
Buno
----------------------------------------
L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai...
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 17 nov. 2010 à 20:17
Salut,
Juste une remarque pour buno à propos de CloseHandle(). Cette fonction ne provoque pas l'arrêt du thread. Elle ne fait que fermer son handle quand il n'est plus utilisé. Un thread se termine de lui même quand il atteint un "return" dans sa fonction. Pour terminer proprement un thread on peut utiliser une variable globale qu'on doit tester à chaque itération de la boucle infinie pour décider d'en sortir ou non. Cette variable jouera le rôle d'un flag à positionner suite au clic sur le bouton "Stop" par exemple. Une autre solution consiste à mettre une boucle de message dans le code de la fonction du thread. Ainsi, ce dernier recevra, entre autres, un message provoquant la sortie de cette boucle. On utilise PostThreadMessage() pour envoyer un message à un thread. Les deux méthodes permettent au thread de se nettoyer, si besoin est, avant de se terminer. TerminateThread() est à éviter.
cs_talonneur
Messages postés8Date d'inscriptionmardi 17 février 2004StatutMembreDernière intervention22 février 2013 17 nov. 2010 à 16:35
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
Vous n’avez pas trouvé la réponse que vous recherchez ?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 18 nov. 2010 à 12:57
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.
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.
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 18 nov. 2010 à 15:50
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.