J'ai des timers windows dans mon application (SetTimer(...)) qui fonctionne
correctement. Parfois, un de mes timers semble ne plus fonctionner; j'ai
l'impression de ne plus passer dans le case de mon timer:
OnTimer(UNIT id)
{
case MON_TIMER_ID:
}
La fonction est bien appelee car d'autres timers continuent de fonctionner.
J'aimerais savoir s'il est possible que le timer s'arrete a cause de
ressources system basse par exemple. Le probleme n'etant pas facilement
reproductible, vos reponses sont les bienvenus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification" (side-effect) s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel miracle. vérifier que la procedure passée en parametre du SetTimer est bien celle dont on controle l'execution. si on traite le message, vérifier que la proc passée est NULL et que MON_TIMER_ID est comparé à WM_PARAM. et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec MON_TIMER_ID avec des parametres comprometants.
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais bon...
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification"
(side-effect)
s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel
miracle.
vérifier que la procedure passée en parametre du SetTimer est bien celle
dont on controle l'execution.
si on traite le message, vérifier que la proc passée est NULL et que
MON_TIMER_ID est comparé à WM_PARAM.
et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec
MON_TIMER_ID avec des parametres comprometants.
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais
bon...
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification" (side-effect) s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel miracle. vérifier que la procedure passée en parametre du SetTimer est bien celle dont on controle l'execution. si on traite le message, vérifier que la proc passée est NULL et que MON_TIMER_ID est comparé à WM_PARAM. et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec MON_TIMER_ID avec des parametres comprometants.
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais bon...
Blasty
Merci pour ta reponse, mais je voulais savoir si il etait possible que le timer ne soit plus actif a cause de windows ou si ce cas etait tres tres improbable. Bien entendu c'est tres probablement a cause du programme en lui meme mais comme la doc dis que les timer sont des ressources limites et que j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines puissantes...
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification" (side-effect)
c'est un #define
s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel miracle.
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est pas apparu.
vérifier que la procedure passée en parametre du SetTimer est bien celle dont on controle l'execution.
Je ne suis pas sur de comprendre mais le SetTimer est fait dans le constructeur du 'MainFrame.cpp' (si je puis dire)
si on traite le message, vérifier que la proc passée est NULL et que MON_TIMER_ID est comparé à WM_PARAM.
Oui la proc passee est NULL,et MON_TIMER_ID est compare a l'argument de OnTimer(UINT nIDEvent)
et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec MON_TIMER_ID avec des parametres comprometants.
SetTimer peut etre appele plusieurs fois mais avec toujours les memes arguments
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais bon...
merci quand meme. Pour l'instant je pense que la cause relle est un probleme de donnees partagees entre plusieurs threads. (et bien sur sans section critiques...)
Merci pour ta reponse, mais je voulais savoir si il etait possible que le
timer ne soit plus actif a cause de windows ou si ce cas etait tres tres
improbable. Bien entendu c'est tres probablement a cause du programme en lui
meme mais comme la doc dis que les timer sont des ressources limites et que
j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines
puissantes...
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification"
(side-effect)
c'est un #define
s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel
miracle.
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est pas
apparu.
vérifier que la procedure passée en parametre du SetTimer est bien celle
dont on controle l'execution.
Je ne suis pas sur de comprendre mais le SetTimer est fait dans le
constructeur du 'MainFrame.cpp' (si je puis dire)
si on traite le message, vérifier que la proc passée est NULL et que
MON_TIMER_ID est comparé à WM_PARAM.
Oui la proc passee est NULL,et MON_TIMER_ID est compare a l'argument de
OnTimer(UINT nIDEvent)
et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec
MON_TIMER_ID avec des parametres comprometants.
SetTimer peut etre appele plusieurs fois mais avec toujours les memes
arguments
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais
bon...
merci quand meme. Pour l'instant je pense que la cause relle est un probleme
de donnees partagees entre plusieurs threads. (et bien sur sans section
critiques...)
Merci pour ta reponse, mais je voulais savoir si il etait possible que le timer ne soit plus actif a cause de windows ou si ce cas etait tres tres improbable. Bien entendu c'est tres probablement a cause du programme en lui meme mais comme la doc dis que les timer sont des ressources limites et que j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines puissantes...
s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification" (side-effect)
c'est un #define
s'assurer qu'il n'y a pas de KillTimer qui soit passé par on ne sait quel miracle.
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est pas apparu.
vérifier que la procedure passée en parametre du SetTimer est bien celle dont on controle l'execution.
Je ne suis pas sur de comprendre mais le SetTimer est fait dans le constructeur du 'MainFrame.cpp' (si je puis dire)
si on traite le message, vérifier que la proc passée est NULL et que MON_TIMER_ID est comparé à WM_PARAM.
Oui la proc passee est NULL,et MON_TIMER_ID est compare a l'argument de OnTimer(UINT nIDEvent)
et enfin, vérifier que le SetTimer n'est pas appellé plus d'une fois avec MON_TIMER_ID avec des parametres comprometants.
SetTimer peut etre appele plusieurs fois mais avec toujours les memes arguments
c'est un peu du genre "vérifier que l'imprimante est bien allumée", mais bon...
merci quand meme. Pour l'instant je pense que la cause relle est un probleme de donnees partagees entre plusieurs threads. (et bien sur sans section critiques...)
Vincent Burel
"Blasty" wrote in message news:3fa67b9c$0$251$
Merci pour ta reponse, mais je voulais savoir si il etait possible que le timer ne soit plus actif a cause de windows ou si ce cas etait tres tres improbable. Bien entendu c'est tres probablement a cause du programme en
lui
meme mais comme la doc dis que les timer sont des ressources limites et
que
j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines puissantes...
WM_TIMER est un message comme un autre, votre callback sera appelé avec ce message quand celle-ci sera libre. Donc le temps entre deux appels WM_TIMER est variable.
VB
"Blasty" <toto@worldnet.com> wrote in message
news:3fa67b9c$0$251$626a54ce@news.free.fr...
Merci pour ta reponse, mais je voulais savoir si il etait possible que le
timer ne soit plus actif a cause de windows ou si ce cas etait tres tres
improbable. Bien entendu c'est tres probablement a cause du programme en
lui
meme mais comme la doc dis que les timer sont des ressources limites et
que
j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines
puissantes...
WM_TIMER est un message comme un autre, votre callback sera appelé avec ce
message quand celle-ci sera libre. Donc le temps entre deux appels WM_TIMER
est variable.
Merci pour ta reponse, mais je voulais savoir si il etait possible que le timer ne soit plus actif a cause de windows ou si ce cas etait tres tres improbable. Bien entendu c'est tres probablement a cause du programme en
lui
meme mais comme la doc dis que les timer sont des ressources limites et
que
j'en utilise 7 et sachant que le probleme n'arrive pas sur les machines puissantes...
WM_TIMER est un message comme un autre, votre callback sera appelé avec ce message quand celle-ci sera libre. Donc le temps entre deux appels WM_TIMER est variable.
VB
Ambassadeur Kosh
> > s'assurer que MON_TIMER_ID ne subit pas "d'effet de modification" > (side-effect) c'est un #define
et l'exemple deux lignes plus loin dit ça : m_nTimer = SetTimer(1, 2000, 0); KillTimer(m_nTimer);
pourquoi un PTR et pas un UINT. qui a bon ? l'exemple ou l'interpretation du prototype ?
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est
pas apparu. [...]
de donnees partagees entre plusieurs threads. (et bien sur sans section critiques...)
7 timer, ça fait un peu beaucoup quand même. y'a une vraie raison d'en avoir autant ou c'est une forme d'attente active ?
Dominique Vaufreydaz
Bonjour,
j'ai relu la doc : UINT_PTR SetTimer(UINT_PTR nIDEvent, UINT nElapse, void (CALLBACK*lpfnTimer)(HWND,UINT,UINT_PTR,DWORD) ); et l'exemple deux lignes plus loin dit ça : m_nTimer = SetTimer(1, 2000, 0); KillTimer(m_nTimer);
OUiai, deja vu ca... Reste que si tu utilise MFC le OnTimer te file un int...
pourquoi un PTR et pas un UINT. qui a bon ? l'exemple ou l'interpretation du prototype ?
L'exemple je pense...
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est
pas apparu. [...]
de donnees partagees entre plusieurs threads. (et bien sur sans section critiques...)
7 timer, ça fait un peu beaucoup quand même.
5 ca tourne sans probleme.
Sinon notez aussi que la queue des messages est limitee en taille depuis Windows 2000 (voir mon pipo la dessus sur www.lafaqmfc.com) et que cela peut entrainer des pertes de messages (ce qui n'etait pas le cas de NT4, ca peut venir de la. Sachant que perso, je perdait des messages car j'avais pleins de threads qui discutaient entres eux !
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://slmg.imag.fr/ http://slmg-index.imag.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
j'ai relu la doc : UINT_PTR SetTimer(UINT_PTR nIDEvent, UINT nElapse, void
(CALLBACK*lpfnTimer)(HWND,UINT,UINT_PTR,DWORD) );
et l'exemple deux lignes plus loin dit ça :
m_nTimer = SetTimer(1, 2000, 0);
KillTimer(m_nTimer);
OUiai, deja vu ca... Reste que si tu utilise MFC le OnTimer te file
un int...
pourquoi un PTR et pas un UINT.
qui a bon ? l'exemple ou l'interpretation du prototype ?
L'exemple je pense...
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est
pas apparu.
[...]
de donnees partagees entre plusieurs threads. (et bien sur sans section
critiques...)
7 timer, ça fait un peu beaucoup quand même.
5 ca tourne sans probleme.
Sinon notez aussi que la queue des messages est limitee en taille
depuis Windows 2000 (voir mon pipo la dessus sur www.lafaqmfc.com)
et que cela peut entrainer des pertes de messages (ce qui n'etait pas
le cas de NT4, ca peut venir de la. Sachant que perso, je perdait des messages
car j'avais pleins de threads qui discutaient entres eux !
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://slmg.imag.fr/
http://slmg-index.imag.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
j'ai relu la doc : UINT_PTR SetTimer(UINT_PTR nIDEvent, UINT nElapse, void (CALLBACK*lpfnTimer)(HWND,UINT,UINT_PTR,DWORD) ); et l'exemple deux lignes plus loin dit ça : m_nTimer = SetTimer(1, 2000, 0); KillTimer(m_nTimer);
OUiai, deja vu ca... Reste que si tu utilise MFC le OnTimer te file un int...
pourquoi un PTR et pas un UINT. qui a bon ? l'exemple ou l'interpretation du prototype ?
L'exemple je pense...
non, les rares fois ou KillTimer est appele, c'est logge et le log n'est
pas apparu. [...]
de donnees partagees entre plusieurs threads. (et bien sur sans section critiques...)
7 timer, ça fait un peu beaucoup quand même.
5 ca tourne sans probleme.
Sinon notez aussi que la queue des messages est limitee en taille depuis Windows 2000 (voir mon pipo la dessus sur www.lafaqmfc.com) et que cela peut entrainer des pertes de messages (ce qui n'etait pas le cas de NT4, ca peut venir de la. Sachant que perso, je perdait des messages car j'avais pleins de threads qui discutaient entres eux !
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://slmg.imag.fr/ http://slmg-index.imag.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Vincent Burel
"Ambassadeur Kosh" wrote in message news:bo7lce$jnr$
et l'exemple deux lignes plus loin dit ça : m_nTimer = SetTimer(1, 2000, 0); KillTimer(m_nTimer);
pourquoi un PTR et pas un UINT. qui a bon ? l'exemple ou l'interpretation du prototype ?
l'exemple est bon.
Ne pas faire un KillTimer avec le nIDEvent donnée au SetTimer comme il est dit et montré dans la doc MSDN.
Vincent Burel
Ambassadeur Kosh
> > 7 timer, ça fait un peu beaucoup quand même. 5 ca tourne sans probleme.
oui.
mais je me demande si en fait, la véritable solution à son probleme ne serait pas de remplacer les timers par quelque chose de plus adapté. encore faut il savoir à quoi servent les timers. c'était juste une intuition...
> > 7 timer, ça fait un peu beaucoup quand même.
5 ca tourne sans probleme.
oui.
mais je me demande si en fait, la véritable solution à son probleme ne
serait pas de remplacer les timers par quelque chose de plus adapté. encore
faut il savoir à quoi servent les timers. c'était juste une intuition...
> > 7 timer, ça fait un peu beaucoup quand même. 5 ca tourne sans probleme.
oui.
mais je me demande si en fait, la véritable solution à son probleme ne serait pas de remplacer les timers par quelque chose de plus adapté. encore faut il savoir à quoi servent les timers. c'était juste une intuition...
