Quote:
J'initialise mes Timers (SetTimer( ..., ..., NULL)) dans OnInitialUpdate() de CMyView.
Dans OnTimer pour chacun des Timers je lis des données et appelle Invalidate(FALSE) donc indirectement la OnDraw() de CMyView.
C'est correct. Mais c'était le premier point à vérifier.
Bon le comportement que tu décris est un comportement préemptif. Ce qui n'arrive pas quand une seule WndProc est en jeu. Je veux dire que si tu es dans un événement WM_PAINT (i.e tu es dans OnDraw appelé depuis la WndProc), un évémenent WM_TIMER ne peut préempter pour que le flux d'exécution saute dans OnTimer.
On a ça uniquement dans une application multithread. Je pense que ce n'est pas le cas (volontairement) de ton application car sinon ça serait évident et tu ne poserais pas la question.
Alors quoi :?:
J'avoue que je n'ai pas eu le désagrément de faire du MFC depuis un bon moment, aussi je ne me souviens plus très bien.
Mais nous devons forcément regarder 2 threads puisqu'il y a préemption. Le premier est celui de la procédure de fenêtre, la WndProc. Normalement on y touche pas.
Le second est celui de l'application. Ca ne peut être que lui. La classe CWinApp descend de CWinThread si je me souviens bien, ce qui veut dire que la boucle de pompe des messages (pas la WndProc hein ?) de l'application tourne dans un thread séparé, ce qui est d'ailleurs normal dans une appli Win32.
Mais peut être que ta boucle des messages n'est pas standard. Normalement ça se résume à GetMessage TranslateMessage et DistpachMessage. Si en amont il y a un appel supplémentaire à PeekMessage, ça peut permette à un message WM_TIMER de préempter une WndProc.
Il me semble me souvenir avoir déjà vu ça...
En espérant que ça t'aide.
C'est correct. Mais c'était le premier point à vérifier.
Bon le comportement que tu décris est un comportement préemptif. Ce qui n'arrive pas quand une seule WndProc est en jeu. Je veux dire que si tu es dans un événement WM_PAINT (i.e tu es dans OnDraw appelé depuis la WndProc), un évémenent WM_TIMER ne peut préempter pour que le flux d'exécution saute dans OnTimer.
On a ça uniquement dans une application multithread. Je pense que ce n'est pas le cas (volontairement) de ton application car sinon ça serait évident et tu ne poserais pas la question.
Alors quoi :?:
J'avoue que je n'ai pas eu le désagrément de faire du MFC depuis un bon moment, aussi je ne me souviens plus très bien.
Mais nous devons forcément regarder 2 threads puisqu'il y a préemption. Le premier est celui de la procédure de fenêtre, la WndProc. Normalement on y touche pas.
Le second est celui de l'application. Ca ne peut être que lui. La classe CWinApp descend de CWinThread si je me souviens bien, ce qui veut dire que la boucle de pompe des messages (pas la WndProc hein ?) de l'application tourne dans un thread séparé, ce qui est d'ailleurs normal dans une appli Win32.
Mais peut être que ta boucle des messages n'est pas standard. Normalement ça se résume à GetMessage TranslateMessage et DistpachMessage. Si en amont il y a un appel supplémentaire à PeekMessage, ça peut permette à un message WM_TIMER de préempter une WndProc.
Il me semble me souvenir avoir déjà vu ça...
En espérant que ça t'aide.