Probleme avec CTimer dans une vue d'une appli

Version imprimable

22/08/2011, 15h03
vdaanen

Probleme avec CTimer dans une vue d'une appli

Bonjour a tous,

en désespoir de cause (et en espérant avoir fait une bêtise si grosse que je ne la vois pas :oops:), je me tourne vers vous.

Voici le probleme : j'ai une appli qui deroule un protocole et chaque etape graphique du protocole est affiché via des CDialog.

Dans plusieurs vues, j'utilise des Timers (CTimer via SetTimer/KillTimer/OnTimer) et ca marche nickel depuis des lustres..
Recemment, j'ai du refactoré une vue (appelons la vue_problématique) et j'ai besoin d'un Timer dans cette derniere et la stupeur, le timer ne fonctionne pas.

J'ai bien la macro ON_WM_TIMER dans la map des messages, ainsi que la methode

Code:

afx_msg void OnTimer(UINT nIDEvent);

declarée et implementée mais je n'y passe jamais alors que l'appel au SetTimer est ok.

Plus etrange encore, les timers de la vue generique sont desactivés le temps que cette vue_problématique est affichée. C'est comme si j'avais declenché une commande qui desactive tous les timers des l'appli qd cette vue_problématique est affichée. Des que je la quitte, tout refonctionne correctement ! 8O

Y aurait-il une methode d'un CDialog ou CWnd connue pour desactiver les timers ?

Si quelqu'un a une idée, une suggestion, je suis preneur car je ne sais vraiment plus quoi faire pour trouver l'origine de ce probleme !

Merci
22/08/2011, 17h35
bacelar

J'ai l'impression que vous utilisez des Timer de fenêtre et non des Timer système.

Ces Timer de fenêtre reposent sur la pseudo-génération d'un message de fenêtre WM_TIMER.

Ce mécanisme simplifie la programmation par l'utilisation de routine dans le thread graphique et pas de fonction de callback dans des threads différents.

Mais ce mécanisme est sujet à beaucoup d'interférence dont la génération intempestives d'autres messages plus prioritaires. Et je ne suis même pas sur que WM_TIMER passe avec WM_PAINT, je pense même le contraire.

Résultat de mes supputations, vos timers ne se déclenchent pas car votre "vue_problématique" génère probablement en continu des messages WM_PAINT (directement ou via Invalidate()).
22/08/2011, 17h53
vdaanen

Bonsoir

Citation:

Envoyé par bacelar

J'ai l'impression que vous utilisez des Timer de fenêtre et non des Timer système.

Effectivement. Comment utilise-t-on des timers systeme ?

Citation:

Envoyé par bacelar

Ces Timer de fenêtre reposent sur la pseudo-génération d'un message de fenêtre WM_TIMER.

Ce mécanisme simplifie la programmation par l'utilisation de routine dans le thread graphique et pas de fonction de callback dans des threads différents.

Mais ce mécanisme est sujet à beaucoup d'interférence dont la génération intempestives d'autres messages plus prioritaires. Et je ne suis même pas sur que WM_TIMER passe avec WM_PAINT, je pense même le contraire.

Résultat de mes supputations, vos timers ne se déclenchent pas car votre "vue_problématique" génère probablement en continu des messages WM_PAINT (directement ou via Invalidate()).

Je viens de faire le test et le message WM_PAINT est appelé une fois lors du rendu initial de la page.
Ensuite, cette page attend l'arrivée de données par reseau (images medicales). Le Timer me sert a detecter que l'envoi des images est terminé pour mettre a jour le GUI.
Durant l'attente, aucun appel a OnPaint (tracé via la macro TRACE) :(

Le mystere reste entier ....

V
22/08/2011, 18h29
bacelar

Utilisez Spy++ pour espionner les messages reçus par une fenêtre.

Utilisez vous des MessageBox, ou autres Dialogues modales ?
http://www.ms-news.net/f3291/my-dial...s-2682902.html
23/08/2011, 10h30
TheGzD

Peut-on voir le code de la fenêtre incriminée ?
23/08/2011, 11h05
vdaanen

Citation:

Envoyé par TheGzD

Peut-on voir le code de la fenêtre incriminée ?

umh, ca va etre difficile car faudrait que je poste plusieurs fichiers (et en + c'est du code d'entreprise....)

Mais dis moi ce que tu veux savoir, je te repondrai de maniere la precise
23/08/2011, 11h13
bacelar

Résultats avec Spy++.
Comment la vue est instanciée ?
Où sont créés les timers ?
Les initialisations dans la routine OnInitDialog ?
23/08/2011, 11h24
vdaanen

Citation:

Envoyé par bacelar

Résultats avec Spy++.

Dans cette vue, le seul message recu est WM_GETICON (si on ne bouge pas la souris ou autre interaction...)

Citation:

Envoyé par bacelar

Comment la vue est instanciée ?

Elle est créée a l'aide de la methode CreateIndirect. Elle est instanciée par la vue principale de l'application.

On n'utilise pas le classwizard et tout le reste car nos applis ont des GUIs differents des GUIs classique Windows

Je tiens a (re)préciser que la facon de faire ci-dessus fonctionne a merveille avec d'autres vue...

Citation:

Envoyé par bacelar

Où sont créés les timers ?

Le timer est créé (SetTimer) dans une methode de la vue lorsqu'un fichier est recu dans un dossier. La creation se passe bien (code appelé, retour de SetTimer correct)

Citation:

Envoyé par bacelar

Les initialisations dans la routine OnInitDialog ?

Rien si ce n'est l'appel a CDialog::OnInitDialog (avec test de la valeur de retour)

A tiens, juste un point que je viens de noter : les timers fonctionnent bien dans des vues qui occupent une partie de l'ecran uniquement, sans recouvrir la vue principale. En revanche, la vue_problématique occupe tout l'espace ecran de la vue principale (recouvrement complet)... Mais ce qui est etrange, c'est que meme la vue principale ne recoit pas le OnTimer...
23/08/2011, 14h56
vdaanen

Citation:

Envoyé par vdaanen

A tiens, juste un point que je viens de noter : les timers fonctionnent bien dans des vues qui occupent une partie de l'ecran uniquement, sans recouvrir la vue principale. En revanche, la vue_problématique occupe tout l'espace ecran de la vue principale (recouvrement complet)... Mais ce qui est etrange, c'est que meme la vue principale ne recoit pas le OnTimer...

j'ai fait des tests ce matin et que la vue_problematique recouvre ou pas la vue principale ne change rien :cry:

Je n'y comprends rien.. je viens de verifier dans d'autres endroits de l'appli et le meme code fonctionne :aie:

comment savoir si les messages sont interceptés a plus haut niveau dans l'appli ?
23/08/2011, 16h01
TheGzD

Pour t'aider j'ai besoin de voir ton code, ça peut venir de tellement de choses et malheureusement je ne suis pas extralucide ...

Si ça peut t'aider utilise MessageSender qui te permettra d'injecter ton WM_TIMER à ta fenêtre, et ainsi d'en tester le réception (tu sauras au moins si n'est pas cela qui plante).
23/08/2011, 16h13
vdaanen

Citation:

Envoyé par TheGzD

Pour t'aider j'ai besoin de voir ton code, ça peut venir de tellement de choses et malheureusement je ne suis pas extralucide ...

Je me doute ma cf mon post precedent, je ne peux pas poster de code sur le forum :(

Citation:

Envoyé par TheGzD

Si ça peut t'aider utilise MessageSender qui te permettra d'injecter ton WM_TIMER à ta fenêtre, et ainsi d'en tester le réception (tu sauras au moins si n'est pas cela qui plante).

aussitôt dit aussitôt fait et .... le message est bien recu :roll: (le GUI s'est mis a jour comme il faut) ...
Donc c'est je ne sais pas quoi qui plante ...
SetTimer(TIMER_ID,3000,0), ca declenche bien le Timer 5 pour une periode de 3000 millisecondes cad 3 secondes et ca declenche un appel de la methode OnTimer .....

J'y comprends rien !

Merci de ton aide

Si quelqu'un a d'autres idees/suggestions, n'hesitez pas...
23/08/2011, 16h21
TheGzD

Citation:

SetTimer(TIMER_ID,3000,0), ca declenche bien le Timer 5 pour une periode de 3000 millisecondes cad 3 secondes et ca declenche un appel de la methode OnTimer .....

Pas tout à fait (voir ici).

Autres questions :
TIMER_ID est-elle correcte ?
Ta fenêtre est-elle bloquante ? threadée ?
23/08/2011, 16h25
vdaanen

Citation:

Envoyé par TheGzD

Pas tout à fait (voir ici).

Autres questions :
TIMER_ID est-elle correcte ?
Ta fenêtre est-elle bloquante ? threadée ?

bon, j'ai oublié de spécifier que TIMER_ID=5(c'est une constante de la classe)
la fenetre n'est pas bloquante ni threadée et ce niveau de l'appli
23/08/2011, 16h30
TheGzD

Si tu peux montre moi la portion de code qui instancie la fenêtre ainsi que la section où tu fais le SetTimer (et précise bien où s'exécute ces codes).
24/08/2011, 08h01
vdaanen

merci a tous de votre aide.
Pour respecter le planning, j'ai changé de techno (Timeout basee sur boost::asio + boost::signal) et ca marche nickel du 1er coup 8O
Je ne comprends toujours pas pourquoi tous les timers sont desactivés dans cette vue .... et je ne le saurai probablement jamais :(

V
24/08/2011, 10h37
bacelar

Le plus probable, c'est une non génération du message WM_TIMER.
2 explications, parmi d'autres :
- génération d'autres messages en "permanence", rendant impossible le passage dans OnIdle des MFC donc la génération des WM_TIMER.
- utilisation de fenêtres modales qui utilisent une autre pompe à message que les CWnd des MFC, donc pas de passage dans OnIdle des MFC.

Vous avez une illustration des grosses limitations des Timer MFC.
Je ne connais pas boost::asio ni boost::signal, mais il y a de bonne chance que ces limitations n'existent pas (mais je pense qu'il y aura un coup dans le codage pour les aspects multi-threading).

Si vos équipes, développement et TMA, sont aguerris au multithreading sous Windows, votre solution à base de boost::asio et boost::signal sera une approche pérenne.
24/08/2011, 11h19
vdaanen

Bonjour,

Citation:

Envoyé par bacelar

Le plus probable, c'est une non génération du message WM_TIMER.

come ecrit plus haut, le seul message recu etait WM_GETICON qui est envoye par le taskmanager pour determiné si l'appli reponds ou non...

Citation:

Envoyé par bacelar

2 explications, parmi d'autres :
- génération d'autres messages en "permanence", rendant impossible le passage dans OnIdle des MFC donc la génération des WM_TIMER.

a priori non, cf ci-dessus.
En revanche, le fait d'injecter un message WM_TIMER via MessageSender declenchait la bonne reaction de l'appli

Citation:

Envoyé par bacelar

- utilisation de fenêtres modales qui utilisent une autre pompe à message que les CWnd des MFC, donc pas de passage dans OnIdle des MFC.

non, pas de fenetre modale a ce niveau :(

Citation:

Envoyé par bacelar

Vous avez une illustration des grosses limitations des Timer MFC.
Je ne connais pas boost::asio ni boost::signal, mais il y a de bonne chance que ces limitations n'existent pas (mais je pense qu'il y aura un coup dans le codage pour les aspects multi-threading).

Si vos équipes, développement et TMA, sont aguerris au multithreading sous Windows, votre solution à base de boost::asio et boost::signal sera une approche pérenne.

nous sommes dans un process de nous affranchir des MFCs et qd je vois le temps que j'ai passé sur ce pb, je me dis qu'on ne peut que gagner a passer sous autre chose (le choix etant Qt en l'occurence ici...)