Discussion :

[romeo9423]

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

[Ti-R]

Sous visual en MFC

Code :

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

SetTimer(1, 2000, 0);

cela envoye un message WM_TIMER

reprit par la fonction

Code :

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

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

[mat.M]

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 ....

[romeo9423]

Sous visual en MFC

Code :

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

SetTimer(1, 2000, 0);

cela envoye un message WM_TIMER

reprit par la fonction

Code :

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

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

[Ti-R]

pour pleins de raisons ??

[romeo9423]

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.

[Ti-R]

Je dis Oui

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

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
 
//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);
	}
}

[la drogue c'est mal]

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

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

[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

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.

[romeo9423]

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.

[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 ?

[Ti-R]

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.

[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

[la drogue c'est mal]

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

multi-plateforme et MFC sont une contradiction meme un "minimum de MFC"

[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

[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.

[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

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

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

Merci bien pour tes conseils en tout cas


bigquick

[Ti-R]

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