PostMessage depuis un Thread graphique vers le CMainFrame.

Bonjour à tous,
je vais commencer par détailler mon contexte visual C++/ MFC et ensuite vous exposez mon problème. Je vais faire mon maximum pour être claire ;)

Je travaille sur un prototype d'application avec une fenêtre de type CWnd/OpenGL dans une architecture CWinApp / CMainFrame classique, sans SDI ou MDI (donc pas d'objet dérivé de CView).
Cette application assure également de la reconnaissance de geste (effectué avec un bras à retour d'effort) et cette reconnaissance de geste est assuré à la fréquence graphique puisqu' effectuée dans le thread graphique.

Je veux lancer l'impression de ma fenêtre CWnd/OpenGL après avoir effectué un geste précis reconnu dans mon thread graphique.
J'ai décidé pour cela d'utiliser le couple

Code:

---

PostMessage(AfxGetMainWnd()->m_hWnd ,WM_PRINT_GEO,0,0)/ ON_MESSAGE(WM_PRINT_GEO,OnPrint)

---

avec un define de WM_PRINT_GEO à partir WM_USER.

Je veux donc depuis mon thread graphique, appeler la fonction d'impression implémenté dans le CMainFrame.

Ca "marchouille" mais j'ai des rendus bizarres d'impression, la fenêtre (ou active area de ma CWnd pour être précise) OpenGL imprimée est assez aléatoire avec parfois les dessins du geste assurant l'impression ou alors un cadre noir ou une portion d'écran noir au lieu d'être blanc......
En fait, je pense que le fait de poster un message pour le run windows depuis le thread graphique perturbe le thread graphique et j'imprime un résultat assez aléatoire.

Qu'en pensez-vous?
Puis-je procéder autrement pour lancer l'impression de ma fenêtre qu'avec un PostMessage?

En vous remerciant par avance pour vos suggestions,
bonne journée.

Par "le thread graphique", veux-tu parler du thread créé au démarrage de l'application et ayant une file de message et une pompe à message MFC ?

Si oui, Le PostMessage ne fait que reporter l'appel à la fonction de callback car PostMessage met le message dans la file de message du thread ayant créé la fenêtre. Donc dans notre cas c'est "le thread graphique" qui exécutera "OnPrint", quand le message sera dépilé de la file de message donc bien plus tard.

Si ton application n'est pas en cours de finalisation, je te conseillerais de dissocié le rendu graphique, lourd et mollement temps réel, de la reconnaissance de forme qui devrait, je pense, avoir des conditions temps réel plus dures. En clair, détection de mouvement dans un thread à part et dédié et communication asynchrone avec le thread graphique via PostMessage, par exemple.

Des mes lointains souvenirs OpenGL, c'est une architecture Client/Server et comme ton appel à "OnPrint" est complètement désynchronisé de la fin de restitution de la scène, je ne vois pas comment tu peux avoir quelque chose de correcte. Ne doit-on pas attendre un évènement pour être sur que le rendu de la scène est fini, ou la wglu planque tout cela ?

Re-bonjour à tous!

Bon, j'ai résolu mon problème seule comme une grande! Ca change.....:P
Après analyse de ce qui se passait effectivement, j'ai compris que c'était la barre des tâches windows qui venait se mettre au-dessus de la zone active client OpenGL de la fenêtre de mon application lors de l'impression, c'est sans doute lié à l'icône de l'imprimante qui apparait, bref.
Résultat : j'avais des trucs bizarres au bas de l'impression.

Pour cacher pendant la durée de l'application cette barre des tâches windows:
- dans le COGLViewApp::InitInstance() :

Code:

---

1 2 3 4

//*****************HIDE_TASK_BAR*******************/ HWND hTask = ::FindWindow(_T("Shell_TrayWnd"), _T("")); ::ShowWindow(hTask, SW_HIDE); //***************************************************/

---

- dans le COGLViewApp::ExitInstance()

Code:

---

1 2 3 4

//*****************SHOW_TASK_BAR*******************/ HWND hTask = ::FindWindow(_T("Shell_TrayWnd"), _T("")); ::ShowWindow(hTask, SW_SHOW); //***************************************************/

---

Et pour conclure, un

Code:

---

PostMessage(AfxGetMainWnd()->m_hWnd ,WM_PRINT_GEO,0,0)/ ON_MESSAGE(WM_PRINT_GEO,OnPrint)

---

depuis un thread graphique vers le CFrameWnd ne pose aucun problème, tout est okay.

Bonne journée à tous.

Citation:

---

Envoyé par bacelar

Par "le thread graphique", veux-tu parler du thread créé au démarrage de l'application et ayant une file de message et une pompe à message MFC ?

Si oui, Le PostMessage ne fait que reporter l'appel à la fonction de callback car PostMessage met le message dans la file de message du thread ayant créé la fenêtre. Donc dans notre cas c'est "le thread graphique" qui exécutera "OnPrint", quand le message sera dépilé de la file de message donc bien plus tard.

Si ton application n'est pas en cours de finalisation, je te conseillerais de dissocié le rendu graphique, lourd et mollement temps réel, de la reconnaissance de forme qui devrait, je pense, avoir des conditions temps réel plus dures. En clair, détection de mouvement dans un thread à part et dédié et communication asynchrone avec le thread graphique via PostMessage, par exemple.

Des mes lointains souvenirs OpenGL, c'est une architecture Client/Server et comme ton appel à "OnPrint" est complètement désynchronisé de la fin de restitution de la scène, je ne vois pas comment tu peux avoir quelque chose de correcte. Ne doit-on pas attendre un évènement pour être sur que le rendu de la scène est fini, ou la wglu planque tout cela ?

---

Zut, j'ai posté en même temps que toi, du coup j'ai répondu sans avoir lu tes propos Bacelar, je suis désolée.
Mon thread graphique est géré au niveau du RenderScene() OpenGL par l'intermédiaire d'un objet Scene et j'instancie cet objet Scene dans l'initInstance () de la CWinApp.
Et ma client area OpenGL est créée dans le CMainFrame:

Code:

---

1 2 3 4 5 6 7

// create a view to occupy the client area of the frame if (!m_wndView.Create(NULL, NULL, AFX_WS_DEFAULT_VIEW, CRect(0, 0, 0, 0), this, AFX_IDW_PANE_FIRST, NULL)) { TRACE0("Failed to create view window\n"); return -1; }

---

Pour le coup, je poste bien le message au CMainFrame qui appelle ma fonction d'impression. J'imprime la scene à l'instant t.

Pour l'application elle-même, elle reste un prototype de R&D, je l'ai récupéré en l'état; le jour où ce prototype doit être développé sous forme de vrai logiciel, beaucoup de choses seront reprises, notamment au niveau des threads graphique, haptique et sans doute un nouveau dédié à la reconnaissance de geste, effectivement. Un gros boulot de conception avant quoi :P

Merci encore pour tes suggestions.