|
|
fr.comp.os.ms-windows.programmation
Discussion complète de l'article :
Tutorial : Programmer en 'C' sous windows (L4)
|
Article :
28867
Date :
03-04-2008
From :
Vincent Burel
Sujet :
Tutorial : Programmer en 'C' sous windows (L4)
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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
28868
Date :
03-04-2008
From :
Sylvain SF
Sujet :
Re: Tutorial : Programmer en 'C' sous windows (L4)
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.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
28869
Date :
03-04-2008
From :
Vincent Burel
Sujet :
Re: Tutorial : Programmer en 'C' sous windows (L4)
"Sylvain SF" wrote in message
news:47f4a618$0$898$ba4acef3@news.orange.fr...
> 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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
28870
Date :
03-04-2008
From :
Vincent Burel
Sujet :
Re: Tutorial : Programmer en 'C' sous windows (L4)
"Vincent Burel" wrote in message
news:47f4adc2$0$832$ba4acef3@news.orange.fr...
>
> "Sylvain SF" wrote in message
> news:47f4a618$0$898$ba4acef3@news.orange.fr...
> > 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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
28873
Date :
03-04-2008
From :
Sylvain SF
Sujet :
Re: Tutorial : Programmer en 'C' sous windows (L4)
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 , 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.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
28874
Date :
03-04-2008
From :
Sylvain SF
Sujet :
Re: Tutorial : Programmer en 'C' sous windows (L4)
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.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
|