Discussion :

[NuXxX]

Salut a tous,

Voila je suis actuellement sur projet en MFC avec interface graphique j'ai un souçi je voudrais enfaite executé une fonction encore et encore tant que le bouton est maintenue enfoncé je ne l'ai pas trouver dans les evenements classique quelqu'un pourrait m'aidé ?

Merci.

[3DArchi]

Bonjour,
L'utilisation d'un timer que tu armes quand le bouton s'enfonce et que tu arrêtes lorsque le bouton se relâche pourrait-elle convenir ?

[NuXxX]

Salut,

Au lieu du timer puis-je seulement exécuté ma fonction dans une sorte de boucle infini et des qu'il est relâché on sort de la boucle , enfaite c'est pour un robot et je voudrais faire un bouton avancé et c'est donc plus pratique d'envoyer une trame qui dit au robot d'avancé tant que l'utilisateur maintien le bouton merci de votre aide.

[Gabrielly]

[FAQ][VC++]Comment créer un bouton exécutant une action en continue à l'état enfoncé

[3DArchi]

Salut,
As-tu fait des tests ? Car j'avoue avoir quelques doutes sur les points suivants :
1/ Si ton thread exécute une fonction de type while(1) {blablabla;}, il risque de monopoliser 100% du CPU et ne pas redonner la main au thread IHM -> L'ihm va sembler figer ou au - très saccadé.
2/

Code :

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

1
2
3
4
5
	do
	{
		pBtn->m_pUserActionThreadProc(pBtn->m_pThreadUserData);
	}
	while(::WaitForSingleObject(pBtn->m_hFinished, 0) != WAIT_OBJECT_0);

J'ai quelque doute sur cette attente. Si m_pUserActionThreadProc dure un peu trop longtemps, l'action va continuer à s'exécuter alors que le bouton va être relâché ou la souris va sortir.

[stephdim]

salut,

1/ Si ton thread exécute une fonction de type while(1) {blablabla;}, il risque de monopoliser 100% du CPU et ne pas redonner la main au thread IHM -> L'ihm va sembler figer ou au - très saccadé.

non, c'est le principe meme du thread. Le thread IHM se déroule en parallèle du thread de travail. il n'y aura pas d'IHM figée.

2/ J'ai quelque doute sur cette attente. Si m_pUserActionThreadProc dure un peu trop longtemps, l'action va continuer à s'exécuter alors que le bouton va être relâché ou la souris va sortir.

je ne vois pas de probleme ici non plus. c'est sûr que si le bouton est relaché il ne sera vu qu'a la prochaine itération, donc avec un léger retard.

le code de Gabrielly est bon, je dirais juste un peu trop compliqué pour l'usage qu'il en sera fait ...

personnellement, j'aurais implémenté une pompe à message privée. ce qui se fait couramment, quand on est en présence d'une action "modale"

une action déclenchée par un timer ou dans CWinApp::OnIdle() aurait aussi été une solution possible. maintenant il faut connaitre la "charge" de cette action ... solutions peut être plus contraignantes (il faut que l'action rende la main assez rapidement) mais plus faciles à implémenter.

EDIT : il manque quelque chose dans le code de Gabrielly.
C'est de s'assurer que le thread s'est bien arrêté.
Si l'action est trop longue entre chaque itération, on risque de déclencher plusieurs threads en même temps.

D'autre part, le code pour arrêter le thread (SetEvent) aurait dû être placé dans le Handler "OnCaptureChanged", de façon que si un autre contrôle vole la capture de la souris, on arrête le thread. Dans le code de Gabrielly, le thread restera actif indéfiniment.

Enfin, l'usage d'un "Event" n'etait pas nécessaire. Une simple variable aurait fait l'affaire. C'est le thread IHM qui accède en écriture à la variable. Le thread de travail n'a un accès qu'en lecture. Il n'y a pas de notion d'accès concurrent.

@+

[Gabrielly]

Voici le correctif

[FAQ][VC++]Comment créer un auto repeat bouton.

[3DArchi]

Salut,
Je persiste à dire que passer par un thread n'est pas un bonne idée :
-> Cela crée plus de problèmes que ça n'en résoud : communication inter-thread; accès concurrent aux objets partagés; priorité des threads. Ce n'est pas insurmontable, mais ça rajoute de la complexité là où il n'y en a pas besoin.
-> Le nombre d'action par seconde est indéterminé : l'écart entre un PC un peu vieux, avec pas trop de mémoire et un PC flambant neuf boosté peut être très très important. Cela risque de perturber l'utilisateur final.
Pour toute ces raisons, si j'ai besoin de cette fonctionnalité (et surtout dans le cas où je veux faire avancer un robot), j'utiliserais un timer pour maîtriser la fréquence des actions (éventuellement paramétrable par l'utilisateur) et non pas un thread !

[NuXxX]

Merci beaucoup pour vos réponses je vais lire tout sa et je vous tien au courant merci.