Tutorial : Programmer en 'C' sous windows (L4)

Le
Vincent Burel
hello,

La leçon 4 : Mes premiers Controles Windows
http://pagesperso-orange.fr/vb-audio/fr/pub/programming/Lesson04/Lesson04.htm

Voici donc un exemple de code se proposant de montrer comment fabriquer ses
propres controles Windows.
j'espère avoir fait un topo clair (étant donné le nombre de soirée que ca
m'a pris :-), mais je complèterai surement la section Q and A pour apporter
des précisions

Déjà je peux vous mettre à contribution pour une question :
quand on ouvre une message box (about box ou confirmation de fermeture) le
code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des
dialogues modales), pourtant nous continuons de recevoir des message
WM_TIMER. Comment expliquer ce phénomène simplement ?

VB
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain SF
Le #9743761
Vincent Burel wrote on 03/04/2008 11:12:

Déjà je peux vous mettre à contribution pour une question :
quand on ouvre une message box (about box ou confirmation de fermeture) le
code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des
dialogues modales), pourtant nous continuons de recevoir des message
WM_TIMER. Comment expliquer ce phénomène simplement ?



MessageBox(..) utile sa propre pompe à message pour recevoir les events
destinés au dialogue qu'il contrôle, mais le thread principal (et la
pompe principale) continue de recevoir les msg qui sont destinés à
toutes les fenêtres qu'il contrôle.

on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont
le dialogue modal sont bien redessinées) et tous messages qui ne soit
pas un ""user event"" (event souris ou clavier).

une explication possible est justement qu'un élément modal prive les
autres éléments d'évènements utilisateur (tous les autres events "plus
systèmes" continuant à être diffusés).

Sylvain.
Vincent Burel
Le #9743751
"Sylvain SF" news:47f4a618$0$898$
Vincent Burel wrote on 03/04/2008 11:12:
>
> Déjà je peux vous mettre à contribution pour une question :
> quand on ouvre une message box (about box ou confirmation de fermeture)


le
> code est censé attendre la sortie de l'appel à ce MessageBox (ce sont


des
> dialogues modales), pourtant nous continuons de recevoir des message
> WM_TIMER. Comment expliquer ce phénomène simplement ?

MessageBox(..) utile sa propre pompe à message pour recevoir les events
destinés au dialogue qu'il contrôle, mais le thread principal (et la
pompe principale) continue de recevoir les msg qui sont destinés à
toutes les fenêtres qu'il contrôle.



qui dit "seconde pompe à messages" dit seconde boucle de message, donc
second thread, or il ne me semble pas qu'un nouveau thread se crée à
l'ouverture d'une boite de dialogue modale.

on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont
le dialogue modal sont bien redessinées) et tous messages qui ne soit
pas un ""user event"" (event souris ou clavier).



oui, même des MOUSEMOVE si j'en crois le spy++

une explication possible est justement qu'un élément modal prive les
autres éléments d'évènements utilisateur (tous les autres events "plus
systèmes" continuant à être diffusés).



comment expliquer que notre code attende la sortie de la fonction MessageBox
et qu'il puisse en même temps continuer de faire tourner la boucle de
message ?

VB
Vincent Burel
Le #9743741
"Vincent Burel" news:47f4adc2$0$832$

"Sylvain SF" news:47f4a618$0$898$
> Vincent Burel wrote on 03/04/2008 11:12:
> >
> > Déjà je peux vous mettre à contribution pour une question :
> > quand on ouvre une message box (about box ou confirmation de


fermeture)
le
> > code est censé attendre la sortie de l'appel à ce MessageBox (ce sont
des
> > dialogues modales), pourtant nous continuons de recevoir des message
> > WM_TIMER. Comment expliquer ce phénomène simplement ?
>
> MessageBox(..) utile sa propre pompe à message pour recevoir les events
> destinés au dialogue qu'il contrôle, mais le thread principal (et la
> pompe principale) continue de recevoir les msg qui sont destinés à
> toutes les fenêtres qu'il contrôle.

qui dit "seconde pompe à messages" dit seconde boucle de message, donc
second thread, or il ne me semble pas qu'un nouveau thread se crée à
l'ouverture d'une boite de dialogue modale.



non, c'est vous qui avait raison, mais je reformule, l'appel à MessageBox
(ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans
la boucle de message de la boite de dialogue. Ce n'est plus notre
MessageLoop qui traite les événement mais celle de la boite de dialogue. et
c'est cette boucle qui par le dispatch appelle notre callback avec
l'événement WM_TIMER par exemple.

d'accord ?
VB
Sylvain SF
Le #9743721
Vincent Burel wrote on 03/04/2008 12:12:

MessageBox (ou à toute ouverture de boite de dialogue modale) fait
rentrer le code dans la boucle de message de la boite de dialogue. Ce
n'est plus notre MessageLoop qui traite les événement mais celle de
la boite de dialogue. et c'est cette boucle qui par le dispatch
appelle notre callback avec l'événement WM_TIMER par exemple.



non, c'est bien le GetMessage() / DispatchMessage() de votre main
qui traite l'event WM_TIMER dans la fenêtre principale.

une pompe à message traite tous les messages destinés à la fenêtre
dont le handle est transmis à GetMessage() (2nd parametre), plus
précisemment à cette fenêtre et à tous ses childs ... sauf pour
toute fenêtre qui enregistre un autre event handler via un autre
GetMessage(), c'est le cas de MessageBox, il utilise un
GetMessage(&e, hWnd_du_dialog, ...) qui de fait provoque le
caractère modal et cette gestion séparée.

votre appli a contrario utilise un GetMessage(&e, null, ...)
afin de recevoir les msg pour toutes les fenêtres créés dans le
scope de votre HINSTANCE (toutes sauf celles qui ...).


on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres
sont le dialogue modal sont bien redessinées) et tous messages qui
ne soit pas un ""user event"" (event souris ou clavier).



oui, même des MOUSEMOVE si j'en crois le spy++



et de nombreuses appli. (browser par exemple pour afficher l'URL
d'un tag <a>, mais d'autres avec affichage d'info-bulles) traitent
ce mousemove sans prendre en compte le statut actif ou non de la
fenêtre.

comment expliquer que notre code attende la sortie de la fonction
MessageBox et qu'il puisse en même temps continuer de faire tourner
la boucle de message ?



le code (un code comparable à votre tuto) n'est pas multi-thread,
mais il est quand même réentrant.
l'appel à MessageBox est bloquant pour votre thread principal
unique, cela n'empêche pas le système de réappeler votre
procédure de traitement de message ('MainWindowManageEvent').
le fait que l'appli soit mono-thread implique seulement qu'un
seul message puisse être traité à la fois.

Sylvain.
Sylvain SF
Le #9743711
Sylvain SF wrote on 03/04/2008 14:22:

non, c'est bien le GetMessage() / DispatchMessage() de votre main
qui traite l'event WM_TIMER dans la fenêtre principale.



raté - moi aussi je dois m'y reprendre à 2 fois!

votre procédure MainWindowManageEvent est réentrante comme indiquée
et c'est pour cela que les fenêtres autres que le dialogue modal
continuent à recevoir des messages.

votre thread étant bloqué par MessageBox, le GetMessage() du main
ne reçoit par contre plus les msg et en effet c'est un autre appel
différent de votre DispatchMessage qui invoque votre callback.
maintenant qui et où exactement ? je préfère réserver la réponse
plutôt que de suppoter gratuitement, il reste vraisemblable que
MessageBox distribue directement les events du dialog modal à sa
winProc et récupère puis appelle la winProc d'autres fenêtres pour
les msg destinés à autre HWND.

Sylvain.
Eric M. H.
Le #9740861
Petite histoire, j'ai programmé sous
4 API de gestion de fenetres :
GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi
meme, X-Windows, et un peu de java.

Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.
Sylvain SF
Le #9740851
Eric M. H. wrote on 10/05/2008 00:21:
Petite histoire, j'ai programmé sous
4 API de gestion de fenetres :
GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi
meme, X-Windows, et un peu de java.

Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.



publie ton code X-Window (sans 's' il me semble) et je le reprendrais.
promis personne ne t'obligera à en apprendre l'API, si par contre un
dessinateur de pseudo-ihm-code en naissait, tu as sera informé ;)

Sylvain.
(lassé aussi des TV, OWT, TK, Win32, WTL, MFC, AWT, Swing, ...)
Etienne
Le #9740841
Eric M. H. wrote:

Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.



Fais du .NET.
Les gosses ne font plus que ça, ils cliquent, ils cliquent et hop, une
appli, sans rien comprendre.
Pour quelques roupies, ils sont contents...
Publicité
Poster une réponse
Anonyme