[MFC] Cherche Timer avec thread

Version imprimable

07/03/2005, 10h07
romeo9423

[MFC] Cherche Timer avec thread

Bonjour,

je souhaiterais utiliser un thread pour gerer des actions à intervalles reguliers (un timer quoi) mais je ne trouve pas mon bonheur sur le net pour le moment.
J'ai trouvé ca :

http://www.codeguru.com/Cpp/misc/misc/timers/article.php/c341/ mais ca n'a pas l'air de fonctionner chez moi.

et pour le moment j'utilise ca :
une classe qui utilise un "Multimedia Timer"
http://www.codeproject.com/audio/mult_media_timer.asp
mais je n'aime pas la dependance a la dll de windows et surtout je n'ai pas besoin de tant de precisions.

Donc si vous avez un code aussi simple que le premier lien mais qui fonctionne pourriez vous partager votre savoir.

Merci

[ Modéré par BigBoomShakala ] - Modification du titre
07/03/2005, 10h27
Ti-R

Sous visual en MFC

Code:

SetTimer(1, 2000, 0);

cela envoye un message WM_TIMER

reprit par la fonction

Code:

OnTimer(UINT nIDEvent)

Pour SetTimer dans l'exemple ci dessus
nIDEvent = 1
2000 représente un envoye du message toutes les 2s.

Ne pas oublier d'appeller KillTimer(1);
Pour tuer le timer numéroté 1 !!

Voila :)
07/03/2005, 11h00
mat.M

Citation:

mais je n'aime pas la dependance a la dll de windows et surtout je n'ai pas besoin de tant de precisions.

J'ai rarement vu , depuis que je fréquente ce forum une remarque aussi stupide : qu'est-ce que ça veut dire pas de dépendances "à la dll de windows" ?

A ce moment là faut pas prendre MFC ni programmer sous Windows !

N'IMPORTE quel programme conçu pour tourner pour Windows ( VB, Delphi , Access ) DEPEND des dll de Windows!
Toutes les fonctionnalités pour afficher des boutons des fenêtres faire des tracés graphiques ,les timers etc...reposent sur les dll systèmes de Windows
Alors une dll en plus ou en moins ....
07/03/2005, 14h35
romeo9423

Citation:

Envoyé par Ti-R

Sous visual en MFC

Code:

SetTimer(1, 2000, 0);

cela envoye un message WM_TIMER

reprit par la fonction

Code:

OnTimer(UINT nIDEvent)

Pour SetTimer dans l'exemple ci dessus
nIDEvent = 1
2000 représente un envoye du message toutes les 2s.

Ne pas oublier d'appeller KillTimer(1);
Pour tuer le timer numéroté 1 !!

Voila :)

Merci mais je ne veux pas utiliser de Timer windows pour pleins de raisons
07/03/2005, 14h47
Ti-R

pour pleins de raisons ??
07/03/2005, 16h18
romeo9423

Citation:

Envoyé par Ti-R

pour pleins de raisons ??

Pourquoi suis je obligé de me justifier ?
Enfin bon.
Les timers qui fonctionnent avec SetTimer sont appropriés pour des petits traitements car ils utilisent le système de message de windows.
Ce qui signifie que parfois le timer ne répond plus lorsqu'ils recoit trop de messages à traiter.
De plus dans certaines situations tu bloques ton interface tjrs a cause du meme probleme car cette derniere fonctionne elle aussi avec des messages.

Je dis Oui :)

Sinon tu lances un thread, dans le thread tu fais un petit calcul du type

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
//speudo code -> algo
 
thread_timer()
{
	while(!b_kill_thread)
	{
		long t_begin = getCurrentTime();
 
		// lance la fonction
 
		long t_time_elapse = getCurrentTime()-t_begin;
		wait(time_to_wait-t_time_elapse);
	}
}

07/03/2005, 22h34
la drogue c'est mal

Citation:

Envoyé par romeo9423

Citation:

Envoyé par Ti-R

pour pleins de raisons ??

Pourquoi suis je obligé de me justifier ?
Enfin bon.
Les timers qui fonctionnent avec SetTimer sont appropriés pour des petits traitements car ils utilisent le système de message de windows.
Ce qui signifie que parfois le timer ne répond plus lorsqu'ils recoit trop de messages à traiter.
.

non si tu utilises le 3e pamaretre de SetTimer

Citation:

De plus dans certaines situations tu bloques ton interface tjrs a cause du meme probleme car cette derniere fonctionne elle aussi avec des messages

non plus. Si c'est le cas, cela ne vient pas du timer ou des messages mais de l'architecture
07/03/2005, 22h44
Ti-R

Mais c'est vrai que WM_TIMER peut avoir un peu de retard...
Cela vient de l'appli généralement mais peut venir d'ailleurs....

Mais bon ce n'est pas le cas général !
Et comme tu l'as si bien dis dans tes besoins romeo9423

Citation:

et surtout je n'ai pas besoin de tant de precisions

WM_TIMER peut être la bonne solution comme le resouligne "la drogue c'est mal"
Facile d’utilisation… je l’utilise personnellement dans toutes mes petites applications développées rapidement sous windows, et je n’ai pas de problème.
08/03/2005, 13h48
romeo9423

Citation:

Envoyé par mat.M

Citation:

mais je n'aime pas la dependance a la dll de windows et surtout je n'ai pas besoin de tant de precisions.

J'ai rarement vu , depuis que je fréquente ce forum une remarque aussi stupide : qu'est-ce que ça veut dire pas de dépendances "à la dll de windows" ?

A ce moment là faut pas prendre MFC ni programmer sous Windows !

N'IMPORTE quel programme conçu pour tourner pour Windows ( VB, Delphi , Access ) DEPEND des dll de Windows!
Toutes les fonctionnalités pour afficher des boutons des fenêtres faire des tracés graphiques ,les timers etc...reposent sur les dll systèmes de Windows
Alors une dll en plus ou en moins ....

Si je n'aime pas cette dependance c'est que je pense en permanence aux multiplateforme. C'est la raison pour laquelle je me limite aux MFC pour le strict minimum et quand je peux j'utilise la STL.
Si demain mon boss vient me voir et me demande :

au fait tu peux porter l'appli sous Linux ?
Je pourrais lui repondre oui assez facilement.
08/03/2005, 14h21
bigquick

C'est (je pense) une très bonne raison.
j'ai actuellement le même problème, et je pense aussi utiliser des threads pour gérer mon timer, avec OpenThreads par exemple (bibliothèque multiplateforme).

Mais du coup, j'ai toujours le problème (cf. l'autre post http://www.developpez.net/forums/viewtopic.php?t=307815) qui consiste à accéder a ma vue à partir de la thread (ou du callback, ça revient au même).

Comment compte-tu t'y prendre ?
08/03/2005, 15h06
Ti-R

Citation:

Envoyé par romeo9423

Citation:

Envoyé par mat.M

Citation:

mais je n'aime pas la dependance a la dll de windows et surtout je n'ai pas besoin de tant de precisions.

J'ai rarement vu , depuis que je fréquente ce forum une remarque aussi stupide : qu'est-ce que ça veut dire pas de dépendances "à la dll de windows" ?

A ce moment là faut pas prendre MFC ni programmer sous Windows !

N'IMPORTE quel programme conçu pour tourner pour Windows ( VB, Delphi , Access ) DEPEND des dll de Windows!
Toutes les fonctionnalités pour afficher des boutons des fenêtres faire des tracés graphiques ,les timers etc...reposent sur les dll systèmes de Windows
Alors une dll en plus ou en moins ....

Si je n'aime pas cette dependance c'est que je pense en permanence aux multiplateforme. C'est la raison pour laquelle je me limite aux MFC pour le strict minimum et quand je peux j'utilise la STL.
Si demain mon boss vient me voir et me demande :

au fait tu peux porter l'appli sous Linux ?
Je pourrais lui repondre oui assez facilement.

Fait gaffe car la MFC s'incruste très rapidement dans le code, et pour en décoller dur dur....
Et ton compilateur Visual C++ a rien à voir avec du GCC...
Essaye de compiler 2-3 classes spécifiques, tu vas rire jaune ;)

Ok la plupart des class fonctionnes mais compter porter du jour au lendemain un gros logiciel d’une plateforme à une autre… j’y crois pas trop si on utilise pas que du cross plateforme en essayant de prendre en compte déjà le multi plateforme.
08/03/2005, 15h14
bigquick

Vraiment tu penses que ce n'est pas faisable ?
Je suis justement en train de développer une application multi-plateforme, et je prévois d'utiliser le minimum de code MFC.

Donc de bien limiter les interactions IHM <-> Gestion des données, de façon à pouvoir facilement passer à wxWidgets, ou Qt, ou tout autre système de fenêtrage, quand il faudra passer le tout sous Linux.

Je pensais que c'était faisable, mais tu me décourage un peu :cry:
08/03/2005, 15h28
la drogue c'est mal

Citation:

Envoyé par bigquick

Vraiment tu penses que ce n'est pas faisable ?
Je suis justement en train de développer une application multi-plateforme, et je prévois d'utiliser le minimum de code MFC.

Donc de bien limiter les interactions IHM <-> Gestion des données, de façon à pouvoir facilement passer à wxWidgets, ou Qt, ou tout autre système de fenêtrage, quand il faudra passer le tout sous Linux.

Je pensais que c'était faisable, mais tu me décourage un peu :cry:

multi-plateforme et MFC sont une contradiction meme un "minimum de MFC"
08/03/2005, 15h33
bigquick

Aie :(

C'est dommage parceque c'est tout ce que j'ai en attendant d'avoir une licence Qt ... Ca sent le boulot fait en double :(
08/03/2005, 15h35
Ti-R

J'ai pas dis que cela était impossible loin de la, mais disons que moi aussi je suis partisan de faire ma propre bibliothèque crossplatform, je l'avais un moment réécrite en C/C++ sans MFC loin de la, juste de l'OpenGL et disons que cela compilait parfaitement sous Visual C++ mais sur un portage Irix ma bibliothèque ne compilait pas du tout, pleins d'erreur de syntaxe que Visual C++ laisse de côté et fait avec... donc une fois que tu as corrigé pas mal "d'erreur" de syntaxe pour t'aligner sur les souhaits du compilateur, je me suis heurté à une de mes class qui utilise union, et j'ai jamais réussi à la compiler dans la manière dont je voulait l'implémenter... Je ne dis pas que c'est impossible, je pense aussi que le compilateur GCC fourni sur Irix que nous avions n'était pas la dernière release loin de la, mais bon il faut s'attendre à pas mal de surprise quand même.

Et si tu utilises des fonctions qui te semblent compatible, elles ne le sont pas forcément.

Exemple: Socket, OpenAL.

Il ne faut pas grand chose pour les rendre compatibles, mais il y a quand même du boulot, plus qu'on ne peut croire/espérer.

ps: C'est juste pour pas que tu parles trop vite à ton patron en disant, c'est facile et "assez" rapide ;)
Il vaut mieux indiquer que tu as conçu le code pour, mais qu'il faut vraiment prospecter en profondeur pour vérifier et porter le code, car il y a toujours intrinsèquement des problèmes. :)
09/03/2005, 10h23
bigquick

En fait je n'avais jamais porté d'application d'une plateforme à une autre, et avec toutes les libs multi-plateforme qu'on trouve par-ci par là ça me paraissait simple :oops:

C'est vrai qu'il vaut peut-être mieux prévoir que ça pourra être difficile et nécessiter du travail, au risque d'avoir une bonne nouvelle le jour venu :wink:

J'espère que ca se passera bien pour romeo9423 aussi

Merci bien pour tes conseils en tout cas

bigquick
09/03/2005, 10h33
Ti-R

De rien, et il faut le prendre pour ce qu'ils sont, un avis personnel :)