Hello,
Si on veut un dialog modal on utilise DialogBox.
Si on en veut pas c'est CreateDialog + sa boucle des msg.
Pblm : DialogBox appelle IsDialogMessage ce qui filtre certains messages
claviers.
Question : comment créer avec CreateDialog une boite modale ? (ou comment
utiliser DialogBox sans IsDialogMessage ?)
Plus généralement, disons avec CreateWindow, comment fonctionne la
"modalité" ?
Merci.
EnableWindow(FALSE) ? Peut-être ... Le seul problème éventuel serait que ça grise des contrôles, ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> Question : comment restreins-tu un SetCapture "au niveau de
l'application"
?
Normalement c'est implicite. D'après la doc, "This function cannot be used to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple : lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le 1° point et laisse le bouton enfoncé, balade toi partout à l'écran. Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le trait de preview comme il faut. Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit visiblement pas WM_MOUSEMOVE. Ce n'est pas le cas avec une boite modale, si tu sors de la boite les autres fenêtres restent "sollicitables".
Donc ni EnableWindow(FALSE), ni SetCapture, ... mais alors, comment font-ils ? Je ne vois que la solution de filtrer les messages avant de faire un DispatchMessage. S'ils sont destinés à la fenêtre mère hop censuré. Mais du coup ça me parrait encore plus complexe à réaliser.
-- Aurélien REGAT-BARREL
> > C'est pas plus simple via un disable ?
EnableWindow(FALSE) ?
Peut-être ... Le seul problème éventuel serait que ça grise des contrôles,
ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> Question : comment restreins-tu un SetCapture "au niveau de
l'application"
?
Normalement c'est implicite. D'après la doc, "This function cannot be used
to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple :
lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le 1°
point et laisse le bouton enfoncé, balade toi partout à l'écran.
Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le
trait de preview comme il faut.
Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit
visiblement pas WM_MOUSEMOVE.
Ce n'est pas le cas avec une boite modale, si tu sors de la boite les autres
fenêtres restent "sollicitables".
Donc ni EnableWindow(FALSE), ni SetCapture, ... mais alors, comment font-ils
?
Je ne vois que la solution de filtrer les messages avant de faire un
DispatchMessage. S'ils sont destinés à la fenêtre mère hop censuré. Mais du
coup ça me parrait encore plus complexe à réaliser.
EnableWindow(FALSE) ? Peut-être ... Le seul problème éventuel serait que ça grise des contrôles, ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> Question : comment restreins-tu un SetCapture "au niveau de
l'application"
?
Normalement c'est implicite. D'après la doc, "This function cannot be used to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple : lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le 1° point et laisse le bouton enfoncé, balade toi partout à l'écran. Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le trait de preview comme il faut. Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit visiblement pas WM_MOUSEMOVE. Ce n'est pas le cas avec une boite modale, si tu sors de la boite les autres fenêtres restent "sollicitables".
Donc ni EnableWindow(FALSE), ni SetCapture, ... mais alors, comment font-ils ? Je ne vois que la solution de filtrer les messages avant de faire un DispatchMessage. S'ils sont destinés à la fenêtre mère hop censuré. Mais du coup ça me parrait encore plus complexe à réaliser.
-- Aurélien REGAT-BARREL
Aurélien REGAT-BARREL
> DialogBox() appelle DialogBoxParam() qui disable la owner et la re-enable en sortie.
Comment est fait ce disabling ? Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains contrôles...
-- Aurélien REGAT-BARREL
> DialogBox() appelle DialogBoxParam() qui disable la owner et la
re-enable en sortie.
Comment est fait ce disabling ?
Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains
contrôles...
> DialogBox() appelle DialogBoxParam() qui disable la owner et la re-enable en sortie.
Comment est fait ce disabling ? Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains contrôles...
-- Aurélien REGAT-BARREL
Patrick 'Zener' Brunet
Bonjour Aurélien.
"Aurélien REGAT-BARREL" a écrit dans le message de news: 415bd5e7$0$25669$
> > C'est pas plus simple via un disable ? > > EnableWindow(FALSE) ? > Peut-être ... Le seul problème éventuel serait que ça grise des
contrôles,
> ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> > Question : comment restreins-tu un SetCapture "au niveau de l'application" > ? > > Normalement c'est implicite. D'après la doc, "This function cannot be
used
> to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple : lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le
1°
point et laisse le bouton enfoncé, balade toi partout à l'écran. Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le trait de preview comme il faut. Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit visiblement pas WM_MOUSEMOVE. Ce n'est pas le cas avec une boite modale, si tu sors de la boite les
autres
fenêtres restent "sollicitables".
Attention, c'est ambigu, il y a différents comportements à envisager pour la capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne serait pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement aux fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter normalement en terminant la capture. Ce qui permet ensuite le changement normal de contexte.
Cordialement,
PZB
Bonjour Aurélien.
"Aurélien REGAT-BARREL" <nospam-aregatba@yahoo.fr.invalid> a écrit dans le
message de news: 415bd5e7$0$25669$626a14ce@news.free.fr...
> > C'est pas plus simple via un disable ?
>
> EnableWindow(FALSE) ?
> Peut-être ... Le seul problème éventuel serait que ça grise des
contrôles,
> ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> > Question : comment restreins-tu un SetCapture "au niveau de
l'application"
> ?
>
> Normalement c'est implicite. D'après la doc, "This function cannot be
used
> to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple :
lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le
1°
point et laisse le bouton enfoncé, balade toi partout à l'écran.
Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le
trait de preview comme il faut.
Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit
visiblement pas WM_MOUSEMOVE.
Ce n'est pas le cas avec une boite modale, si tu sors de la boite les
autres
fenêtres restent "sollicitables".
Attention, c'est ambigu, il y a différents comportements à envisager pour la
capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le
WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne serait
pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de
l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le
cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la
capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement aux
fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la
capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter
normalement en terminant la capture. Ce qui permet ensuite le changement
normal de contexte.
"Aurélien REGAT-BARREL" a écrit dans le message de news: 415bd5e7$0$25669$
> > C'est pas plus simple via un disable ? > > EnableWindow(FALSE) ? > Peut-être ... Le seul problème éventuel serait que ça grise des
contrôles,
> ce qui serait anormal visuellement.
Ah oui, c'est vrai. Du coup c'est pas ça qui est fait alors...
> > Question : comment restreins-tu un SetCapture "au niveau de l'application" > ? > > Normalement c'est implicite. D'après la doc, "This function cannot be
used
> to capture mouse input meant for another process".
Moui, au niveau du clic, mais voici un exemple simple : lance mspaint, clic sur "ligne" (tracer un trait, donc 2 points), clic le
1°
point et laisse le bouton enfoncé, balade toi partout à l'écran. Il capture la mouse, si tu sors de la fenêtre il continue à dessiner le trait de preview comme il faut. Si tu passes sur une autre fenêtre d'un autre process elle ne reçoit visiblement pas WM_MOUSEMOVE. Ce n'est pas le cas avec une boite modale, si tu sors de la boite les
autres
fenêtres restent "sollicitables".
Attention, c'est ambigu, il y a différents comportements à envisager pour la capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne serait pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement aux fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter normalement en terminant la capture. Ce qui permet ensuite le changement normal de contexte.
Cordialement,
PZB
Christian ASTOR
Aurélien REGAT-BARREL wrote:
DialogBox() appelle DialogBoxParam() qui disable la owner et la re-enable en sortie.
Comment est fait ce disabling ? Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains contrôles...
Ca ne disable pas les childs. Windows fait ça au niveau Kernel par NtUserCallHwndParamLock(), mais qui revient au final à un EnableWindow() au niveau User.
Aurélien REGAT-BARREL wrote:
DialogBox() appelle DialogBoxParam() qui disable la owner et la
re-enable en sortie.
Comment est fait ce disabling ?
Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains
contrôles...
Ca ne disable pas les childs.
Windows fait ça au niveau Kernel par NtUserCallHwndParamLock(), mais qui
revient au final à un EnableWindow() au niveau User.
DialogBox() appelle DialogBoxParam() qui disable la owner et la re-enable en sortie.
Comment est fait ce disabling ? Patrick fait remarquer à juste titre que EnbaleWindow(FALSE) grise certains contrôles...
Ca ne disable pas les childs. Windows fait ça au niveau Kernel par NtUserCallHwndParamLock(), mais qui revient au final à un EnableWindow() au niveau User.
Aurelien REGAT-BARREL
> Ca ne disable pas les childs.
Ah ok.
Windows fait ça au niveau Kernel par NtUserCallHwndParamLock(), mais qui revient au final à un EnableWindow() au niveau User
> Attention, c'est ambigu, il y a différents comportements à envisager pour la capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne serait pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement aux fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter normalement en terminant la capture. Ce qui permet ensuite le changement normal de contexte.
Hum... t'avais du bien de faire ch*** quand t'as fait ça :-)
Pour le EnableWindow c'est du cheat : seul le parent est disabled. Merci pour tes explications. A+
> Attention, c'est ambigu, il y a différents comportements à envisager pour
la
capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le
WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne
serait
pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de
l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le
cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la
capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement
aux
fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la
capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter
normalement en terminant la capture. Ce qui permet ensuite le changement
normal de contexte.
Hum... t'avais du bien de faire ch*** quand t'as fait ça :-)
Pour le EnableWindow c'est du cheat : seul le parent est disabled.
Merci pour tes explications.
A+
> Attention, c'est ambigu, il y a différents comportements à envisager pour la capture :
- le comportement en cours de dragging ou de "dessin", utilisant ainsi le WM_MOUSEMOVE, doit être modal au niveau du bureau entier, sinon ça ne serait pas pratique à utiliser.
- par contre, ce qui compte, c'est que les fenêtres parentes de l'application ne reçoivent pas les WM_SETCURSOR émis normalement dans le cadre du traitement de WM_MOUSEMOVE (ce qui est donc réalisé dans la capture),
- et aussi les clics souris, qui par contre doivent parvenir normalement aux fenêtres d'autres applications (et dans ce cas la fenêtre qui a fait la capture doit recevoir en prélude un WM_CANCELMODE qu'elle doit traiter normalement en terminant la capture. Ce qui permet ensuite le changement normal de contexte.
Hum... t'avais du bien de faire ch*** quand t'as fait ça :-)
Pour le EnableWindow c'est du cheat : seul le parent est disabled. Merci pour tes explications. A+
