Discussion :

[vdaanen]

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 ), 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 :

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

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 !

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

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

[vdaanen]

Bonsoir

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 ?

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

[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

[TheGzD]

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

[vdaanen]

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

[bacelar]

Résultats avec Spy++.
Comment la vue est instanciée ?
Où sont créés les timers ?
Les initialisations dans la routine OnInitDialog ?

[vdaanen]

Résultats avec Spy++.

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

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

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)

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

[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

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

comment savoir si les messages sont interceptés a plus haut niveau dans l'appli ?

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

[vdaanen]

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

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

[TheGzD]

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 ?

[vdaanen]

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

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

[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
Je ne comprends toujours pas pourquoi tous les timers sont desactivés dans cette vue .... et je ne le saurai probablement jamais

V

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

[vdaanen]

Bonjour,

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

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

- 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

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