J'utilise GetWindowRect puis SetWindowPos pour redimensionner
dynamiquement un control de texte dans une boite de dialogue.
Tout se passe très bien en config simple écran où quand la boite de
dialogue et la fenêtre de mon application sont affichées sur l'écran
principal en config double écran. En gros, GetWindowRect me renvoit les
coordonnées 22, 147, 113 et 322 pour top, bottom, left et right.
Mais quand la fenêtre de mon application est affichée sur le deuxième
écran et que ma boite de dialogue est sur le premier, GetWindowRect me
renvoit 22, 147, 1137 et 1346 !! Inutile de vous dire qu'avec les
coordonnées suivantes, le SetWindowPos n'arrive pas à afficher le
control de texte dans sa boite de dialogue.
Bref, la boite de dialogue étant toujours à la même place, je n'ai pas
les même coordonnées selon la position de la fenêtre principale de
l'application !
Si quelqu'un a une idée pour résoudre ce problème...
Si quelqu'un a une idée pour résoudre ce problème...
merci
Je n'en ai pas pour ma part, mais je suis sûr qu'ici ils en auront une:
fr.comp.os.ms-windows.programmation
Bon courage
Sylvain
mumu wrote on 23/08/2006 15:29:
J'utilise GetWindowRect puis SetWindowPos pour redimensionner dynamiquement un control de texte dans une boite de dialogue.
Mais quand la fenêtre de mon application est affichée sur le deuxième écran et que ma boite de dialogue est sur le premier, GetWindowRect me renvoit 22, 147, 1137 et 1346 !! Inutile de vous dire qu'avec les coordonnées suivantes, le SetWindowPos n'arrive pas à afficher le control de texte dans sa boite de dialogue.
pas du tout C++ spécifique, mais bon ...
<HC>
vous êtes vraiment tout à fait sur de demander ses coordonnées à la bonne fenêtre ? (le dialog et non le frame principale) ?
si le bug est avéré, un moyen de le contourner est de coder plus directement le resize du control (si celui-ci est ancré sur con coin haut-gauche et s'étends seulement vers la droite et vers le bas), simplement en définissant un handler de WM_SIZE sur le dialog, il viendra alors:
void TheDialog::OnSize(UINT nType, int cx, int cy) { CDialog::OnSize(nType, cx, cy); if (theTextCtrl.m_hWnd) theTextCtrl.SetWindowPos(null, 0, 0, cx - MARGIN_RIGHT, cy - MARGIN_BOTTOM, SWP_NOMOVE | SWP_NOZORDER); }
ceci évite les calculs des différences de tailles entre parent et controles-fils.
</HC>
Sylvain.
mumu wrote on 23/08/2006 15:29:
J'utilise GetWindowRect puis SetWindowPos pour redimensionner
dynamiquement un control de texte dans une boite de dialogue.
Mais quand la fenêtre de mon application est affichée sur le deuxième
écran et que ma boite de dialogue est sur le premier, GetWindowRect me
renvoit 22, 147, 1137 et 1346 !! Inutile de vous dire qu'avec les
coordonnées suivantes, le SetWindowPos n'arrive pas à afficher le
control de texte dans sa boite de dialogue.
pas du tout C++ spécifique, mais bon ...
<HC>
vous êtes vraiment tout à fait sur de demander ses coordonnées à la
bonne fenêtre ? (le dialog et non le frame principale) ?
si le bug est avéré, un moyen de le contourner est de coder plus
directement le resize du control (si celui-ci est ancré sur con coin
haut-gauche et s'étends seulement vers la droite et vers le bas),
simplement en définissant un handler de WM_SIZE sur le dialog, il
viendra alors:
void TheDialog::OnSize(UINT nType, int cx, int cy)
{
CDialog::OnSize(nType, cx, cy);
if (theTextCtrl.m_hWnd)
theTextCtrl.SetWindowPos(null, 0, 0,
cx - MARGIN_RIGHT, cy - MARGIN_BOTTOM,
SWP_NOMOVE | SWP_NOZORDER);
}
ceci évite les calculs des différences de tailles entre parent et
controles-fils.
J'utilise GetWindowRect puis SetWindowPos pour redimensionner dynamiquement un control de texte dans une boite de dialogue.
Mais quand la fenêtre de mon application est affichée sur le deuxième écran et que ma boite de dialogue est sur le premier, GetWindowRect me renvoit 22, 147, 1137 et 1346 !! Inutile de vous dire qu'avec les coordonnées suivantes, le SetWindowPos n'arrive pas à afficher le control de texte dans sa boite de dialogue.
pas du tout C++ spécifique, mais bon ...
<HC>
vous êtes vraiment tout à fait sur de demander ses coordonnées à la bonne fenêtre ? (le dialog et non le frame principale) ?
si le bug est avéré, un moyen de le contourner est de coder plus directement le resize du control (si celui-ci est ancré sur con coin haut-gauche et s'étends seulement vers la droite et vers le bas), simplement en définissant un handler de WM_SIZE sur le dialog, il viendra alors:
void TheDialog::OnSize(UINT nType, int cx, int cy) { CDialog::OnSize(nType, cx, cy); if (theTextCtrl.m_hWnd) theTextCtrl.SetWindowPos(null, 0, 0, cx - MARGIN_RIGHT, cy - MARGIN_BOTTOM, SWP_NOMOVE | SWP_NOZORDER); }
ceci évite les calculs des différences de tailles entre parent et controles-fils.
</HC>
Sylvain.
Alain Gaillard
si le bug est avéré, un moyen de le contourner est de coder plus
Je ne pense pas que ce soit un bug. Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les largeurs des écrans se cumulent.
-- Alain
si le bug est avéré, un moyen de le contourner est de coder plus
Je ne pense pas que ce soit un bug.
Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre
fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les
largeurs des écrans se cumulent.
si le bug est avéré, un moyen de le contourner est de coder plus
Je ne pense pas que ce soit un bug. Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les largeurs des écrans se cumulent.
-- Alain
Sylvain
Alain Gaillard wrote on 24/08/2006 10:14:
Je ne pense pas que ce soit un bug. Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les largeurs des écrans se cumulent.
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Sylvain.
Alain Gaillard wrote on 24/08/2006 10:14:
Je ne pense pas que ce soit un bug.
Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre
fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les
largeurs des écrans se cumulent.
la dimension de la surface de travail est bien une somme de surface des
différents écrans (selon leur disposition logique cote à cote ou l'un en
dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue
(décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le
2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Je ne pense pas que ce soit un bug. Il nous dit qu'une fenêtre de l'appli est dans un écran et qu'une autre fenêtre dans l'autre écran. Dans ce cas il me paraît logique que les largeurs des écrans se cumulent.
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Sylvain.
Alain Gaillard
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus. Mais je ne suis pas certain que le posteur initial ait compris le principe de cumulation des surfaces, et c'est en fait à son attention que j'avais écrit :)
-- Alain
la dimension de la surface de travail est bien une somme de surface des
différents écrans (selon leur disposition logique cote à cote ou l'un en
dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue
(décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le
2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus.
Mais je ne suis pas certain que le posteur initial ait compris le
principe de cumulation des surfaces, et c'est en fait à son attention
que j'avais écrit :)
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus. Mais je ne suis pas certain que le posteur initial ait compris le principe de cumulation des surfaces, et c'est en fait à son attention que j'avais écrit :)
-- Alain
mumu
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus. Mais je ne suis pas certain que le posteur initial ait compris le principe de cumulation des surfaces, et c'est en fait à son attention que j'avais écrit :)
Merci à tous pour vos interventions... Et désolé, j'aurais effectivement du poster cela dans fr.comp.os.ms-windows.programmation qui était plus adéquat...
La cumulation des surfaces, ok, je connaissais, du moins je le pense. En fait je cerchais à redimensionner un control de text en fonction ou non de la présence d'une icone dans la même boite de dialogue. Pour cela je récupérais en premier les coordonnées de mon control en faisant :
Le tout dans le InitDialog de ma boite de dialogue. C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième écran quand ma windows principale est sur le deuxième et mon boite de dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi cela...
Ensuite après repositionnement de mon Rectstatic, je rebalance le tout dans un : pWnd->SetWindowPos(NULL, RectStatic.left, sMargeDuHaut, RectStatic.Width() , sHauteurCtrl, SWP_NOZORDER );
En fait je viens résoudre mon problème en calculant la distance entre mon texte et le bord de la fenêtre après avoir récupérer un CRect de ma dialog box de la même manière.
Du coup je suis quand même étonné de 2 choses : - pour quoi GetWindowRect me renvoi des coordonnées dans l'autre écran? c'est comme si la dialogbox qui doit être child ne pouvait qu'être par dessus la windows principale - SetWindowPos semble travailler en coordonnées relative à ma dialog box alors que je pensais que c'était en coord écran...
Mais bon, j'ai résolu mon problème, c'est là le plus important. Si vous avez un avis sur la question, je serais quand même heureux de le lire...
Vincent
la dimension de la surface de travail est bien une somme de surface
des différents écrans (selon leur disposition logique cote à cote ou
l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue
(décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur
le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus.
Mais je ne suis pas certain que le posteur initial ait compris le
principe de cumulation des surfaces, et c'est en fait à son attention
que j'avais écrit :)
Merci à tous pour vos interventions... Et désolé, j'aurais effectivement
du poster cela dans fr.comp.os.ms-windows.programmation qui était plus
adéquat...
La cumulation des surfaces, ok, je connaissais, du moins je le pense. En
fait je cerchais à redimensionner un control de text en fonction ou non
de la présence d'une icone dans la même boite de dialogue. Pour cela je
récupérais en premier les coordonnées de mon control en faisant :
Le tout dans le InitDialog de ma boite de dialogue.
C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième
écran quand ma windows principale est sur le deuxième et mon boite de
dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi
cela...
Ensuite après repositionnement de mon Rectstatic, je rebalance le tout
dans un :
pWnd->SetWindowPos(NULL, RectStatic.left, sMargeDuHaut,
RectStatic.Width() , sHauteurCtrl, SWP_NOZORDER );
En fait je viens résoudre mon problème en calculant la distance entre
mon texte et le bord de la fenêtre après avoir récupérer un CRect de ma
dialog box de la même manière.
Du coup je suis quand même étonné de 2 choses :
- pour quoi GetWindowRect me renvoi des coordonnées dans l'autre écran?
c'est comme si la dialogbox qui doit être child ne pouvait qu'être par
dessus la windows principale
- SetWindowPos semble travailler en coordonnées relative à ma dialog box
alors que je pensais que c'était en coord écran...
Mais bon, j'ai résolu mon problème, c'est là le plus important.
Si vous avez un avis sur la question, je serais quand même heureux de le
lire...
la dimension de la surface de travail est bien une somme de surface des différents écrans (selon leur disposition logique cote à cote ou l'un en dessous de l'autre); ce point est attendu.
l'erreur éventuelle serait que la lecture des coords. du dialogue (décrit sur 1er écran) donne celles de sa fenêtre parent (placée sur le 2nd écran d'après le PO); je n'ai jamais vu de telles erreurs.
Moi non plus. Mais je ne suis pas certain que le posteur initial ait compris le principe de cumulation des surfaces, et c'est en fait à son attention que j'avais écrit :)
Merci à tous pour vos interventions... Et désolé, j'aurais effectivement du poster cela dans fr.comp.os.ms-windows.programmation qui était plus adéquat...
La cumulation des surfaces, ok, je connaissais, du moins je le pense. En fait je cerchais à redimensionner un control de text en fonction ou non de la présence d'une icone dans la même boite de dialogue. Pour cela je récupérais en premier les coordonnées de mon control en faisant :
Le tout dans le InitDialog de ma boite de dialogue. C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième écran quand ma windows principale est sur le deuxième et mon boite de dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi cela...
Ensuite après repositionnement de mon Rectstatic, je rebalance le tout dans un : pWnd->SetWindowPos(NULL, RectStatic.left, sMargeDuHaut, RectStatic.Width() , sHauteurCtrl, SWP_NOZORDER );
En fait je viens résoudre mon problème en calculant la distance entre mon texte et le bord de la fenêtre après avoir récupérer un CRect de ma dialog box de la même manière.
Du coup je suis quand même étonné de 2 choses : - pour quoi GetWindowRect me renvoi des coordonnées dans l'autre écran? c'est comme si la dialogbox qui doit être child ne pouvait qu'être par dessus la windows principale - SetWindowPos semble travailler en coordonnées relative à ma dialog box alors que je pensais que c'était en coord écran...
Mais bon, j'ai résolu mon problème, c'est là le plus important. Si vous avez un avis sur la question, je serais quand même heureux de le lire...
Vincent
Alain Gaillard
C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième écran quand ma windows principale est sur le deuxième et mon boite de dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi cela...
Parce que c'est conçu comme ça.
c'est comme si la dialogbox qui doit être child ne pouvait qu'être par dessus la windows principale
C'est quelque chose comme ça.
- SetWindowPos semble travailler en coordonnées relative à ma dialog box alors que je pensais que c'était en coord écran...
La MSDN dit bien que x et y sont en coordonnées client.
Si vous avez un avis sur la question, je serais quand même heureux de le lire...
Mon avis est double. - D'abord tu n'es pas le premier à te faire prendre parce que tu n'as pas lu à la loupe la doc Kro$oft. Et je je sais de quoi je parle tant ça m'est arrivé... :-(
- Pour ce genre de discussion, c'est vers un groupe de discussion dédié à la programamtion Windows que tu dois te tourner.
-- Alain
C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième
écran quand ma windows principale est sur le deuxième et mon boite de
dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi
cela...
Parce que c'est conçu comme ça.
c'est comme si la dialogbox qui doit être child ne pouvait qu'être par
dessus la windows principale
C'est quelque chose comme ça.
- SetWindowPos semble travailler en coordonnées relative à ma dialog box
alors que je pensais que c'était en coord écran...
La MSDN dit bien que x et y sont en coordonnées client.
Si vous avez un avis sur la question, je serais quand même heureux de le
lire...
Mon avis est double.
- D'abord tu n'es pas le premier à te faire prendre parce que tu n'as
pas lu à la loupe la doc Kro$oft. Et je je sais de quoi je parle tant ça
m'est arrivé... :-(
- Pour ce genre de discussion, c'est vers un groupe de discussion dédié
à la programamtion Windows que tu dois te tourner.
C'est ce GetWindowRect là qui me renvoit des coordonnées sur le deuxième écran quand ma windows principale est sur le deuxième et mon boite de dialogue sur le premier écran. Je me demande bien pourquoi ça me renvoi cela...
Parce que c'est conçu comme ça.
c'est comme si la dialogbox qui doit être child ne pouvait qu'être par dessus la windows principale
C'est quelque chose comme ça.
- SetWindowPos semble travailler en coordonnées relative à ma dialog box alors que je pensais que c'était en coord écran...
La MSDN dit bien que x et y sont en coordonnées client.
Si vous avez un avis sur la question, je serais quand même heureux de le lire...
Mon avis est double. - D'abord tu n'es pas le premier à te faire prendre parce que tu n'as pas lu à la loupe la doc Kro$oft. Et je je sais de quoi je parle tant ça m'est arrivé... :-(
- Pour ce genre de discussion, c'est vers un groupe de discussion dédié à la programamtion Windows que tu dois te tourner.
