Fenêtre qui s'adapte à toute forme d'écran

Version imprimable

Voir 40 message(s) de cette discussion en une page

24/10/2016, 22h53
pal1996

Fenêtre qui s'adapte à toute forme d'écran

Salut!
je voudrai savoir comment faire à ce que ma fenêtre s'adapte à tout écran quelle que soit sa résolution; et que lorsque je la réduise les contrôles qu'elle contient se réduisent aussi.
Merci!
25/10/2016, 09h16
Bousk

Salut,

Y'a pas vraiment de magie. Faut juste tout prendre en compte et adapter les tailles et positions en fonction. Souvent travailler en % de fenêtre et non en pixels directement est un premier pas.
Edit : et une attention particulière aux éléments circulaires pour pas qu'ils se retrouvent ovales :)
25/10/2016, 11h29
bacelar

Utiliser une librairie graphique qui gère ce genre de chose.
27/10/2016, 14h58
pal1996

J'ai essayé de récupérer les dimensions de la fenêtre cliente dans un ''RECT'' et de travailler en fonction. Mais lorsque je redimensionne la fenêtre ça n'a aucun effet. Est ce qu'il faut alors utiliser les ''%'' pour résoudre le problème ou alors il y'a autre chose à ajouter?
Merci.
27/10/2016, 16h21
Médinoc

Tu utilises directement l'API Win32?
27/10/2016, 19h45
pal1996

Oui, j'utilise la WINAPI.
27/10/2016, 19h59
Médinoc

La WinAPI n'automatise pas le redimensionnement ou réarrangement des contrôles d'une fenêtre (sauf pour certains contrôles comme les toolbar, les rebar qui les contiennent, les statusbar etc.), tu dois donc redimensionner et/ou déplacer manuellement tes contrôles en réponse au message WM_SIZE. Tu peux utiliser la fonction MoveWindow() à cet effet.
27/10/2016, 20h22
pal1996

Donc en gros ce n'est pas possible de de créer en WINAPI une fenêtre qui s'adapte à tout écran quel que soit sa taille?
27/10/2016, 23h23
Médinoc

Si, mais il faut que tu le fasses toi-même. WINAPI n'offre pas de mécanismes automatiques comme ceux de Windows Forms (Layout, Dock, Anchor).
Cela ne t'empêche pas d'en créer: Des bibliothèques comme GTK+ fournissent des Layout, et possèdent une implémentation pour Windows...
28/10/2016, 10h45
pal1996

Ok. Comme j'utilise directement l'API WIN32, je voudrai connaitre s'il vous plait toutes les fonctions, messages, notifications et flags relatifs à celà et que je pourrai utiliser à ce titre.
28/10/2016, 11h37
bacelar

Citation:

Ok. Comme j'utilise directement l'API WIN32, je voudrai connaitre s'il vous plait toutes les fonctions, messages, notifications et flags relatifs à celà et que je pourrai utiliser à ce titre.

Je crois que tu sous estimes largement le travail nécessaire.
Sinon, tout est dans MSDN, comme d'habitude.
28/10/2016, 11h45
Médinoc

Franchement pour réarranger les contrôles quand la fenêtre est redimensionnée, WM_SIZE tend à être suffisant, mais WM_GETMINMAXINFO peut également être utile si tu veux garder fixe l'une des dimensions de ta fenêtre.
Si tu écris toi-même des contrôles, vérifie également les styles de WNDCLASS: CS_VREDRAW et CS_HREDRAW t'évitent d'avoir à appeler manuellement InvalidateRect() dans ton traitement de WM_SIZE.

Et si tu fais des applications plus complexes, la WinAPI donne un support natif pour Multiple Document Interface (MDI), les fenêtres contenant plusieurs fenêtres filles comme documents. Par contre, tu devras traiter WM_SIZE dans tes fenêtres "MDI Child" pour adapter les contrôles à la taille de tes sous-fenêtres, donc ça ne remplace pas.
28/10/2016, 11h58
pal1996

Merci pour vos interventions. J'analyserai tout cela plus en détail et je vous en ferai part.
28/10/2016, 13h07
pal1996

Ça fonctionne comme sur des roulettes. Voici ce que je viens de faire:
-WM_CREATE: Je fais un getWindowRect(), et je crée mes contrôles en fonction du RECT définit.
-WM_SIZE: Je fais encore un getWindowRect() dans le même RECT, et je fais un MoveWindow() pour un contrôle définit.
-Je n'oublie pas de définir le style de la WNDCLASS comme suit : CS_HREDRAW|CS_VREDRAW.

Merci à vous! Vous êtes géniaux!
28/10/2016, 13h40
Médinoc

Normalement, tu as plutôt intérêt à utiliser GetClientRect() que GetWindowRect() pour le placement de tes contrôles.

Note: CS_HREDRAW|CS_VREDRAW, ça tend à être plutôt pour les contrôles (de toute façon, ta fenêtre sera redessinée là où c'est nécessaire quand tu déplaces les contrôles, normalement). En termes simples, si tu ne traites pas toi-même le message WM_PAINT, tu ne devrais pas avoir besoin de CS_H/VREDRAW (mais il faudrait que je vérifie).
28/10/2016, 15h37
Mat.M

Citation:

Envoyé par pal1996

Salut!
je voudrai savoir comment faire à ce que ma fenêtre s'adapte à tout écran quelle que soit sa résolution; et que lorsque je la réduise les contrôles qu'elle contient se réduisent aussi.
Merci!

avant de gérer WM_SIZE et les constantes de création comme CS_VREDRAW de fenêtre encore faudrait-il obtenir la résolution de l'écran courante et je ne comprends pas pourquoi cela n'a pas été mentionné.
C'est possible avec GetSystemMetrics()notamment qui retourne la résolution de l'écran
Donc en fonction de cela on peut redimensionner la fenêtre.

Si l'utilisateur décide de changer de résolution d'écran ce qui est peu courant, le Program Manager contenu dans le noyau de l'OS et qui place les messages dans la boucle de messages(bref captés par GetMessage() TranslateMessage()...) va placer le message WM_SIZE ou WM_PAINT

Donc tout programme développé en C/C++ pour Windows avec l'API win32 devrait gérer en principe GetSystemMetrics()

De même que le message WM_QUERYENDSESSION mais ça c'est une autre affaire..

Citation:

Envoyé par pal1996

-WM_CREATE: Je fais un getWindowRect(), et je crée mes contrôles en fonction du RECT définit.
-WM_SIZE: Je fais encore un getWindowRect() dans le même RECT, et je fais un MoveWindow() pour un contrôle définit.

attention aussi au problème des coordonnées logiques et physiques..le cas échéant on peut être amené à faire une conversion des coordonnées obtenues par le système avec ClientToScreen notamment ou la fonction inverse

Voici un programme d'exemple: En C, compatible avec VS 2005 et des vieux OS comme Windows XP. En gros, ça devrait tourner pratiquement partout:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
#define _WIN32_WINNT 0x501 /*Windows XP ou supérieur (pour ICC_STANDARD_CLASSES)*/
#include <windows.h>
#pragma warning(push)
#pragma warning(disable: 4201) /*Supprime un warning inutile sous Visual 2005*/
#include <commctrl.h>
#pragma warning(pop)
#pragma comment(lib, "comctl32.lib")
 
/*Identifiants de contrôles*/
#define IDC_MYEDITBOX 100
#define IDC_MYTEXT 101
#define IDC_MYBUTTON 102
 
#define HMENU_FROM_CONTROLID(x) ((HMENU)(INT_PTR)(x))
 
/*Pour avoir un affichage moderne, il faut compiler en UNICODE et utiliser Common Controls v6 ou supérieur*/
#ifdef UNICODE
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
 
/*Procédure de fenêtre*/
LRESULT CALLBACK resizing_WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
	LRESULT ret = 0;
	switch(uMsg)
	{
	case WM_CREATE:
		{
			RECT r = {0};
			GetClientRect(hWnd, &r);
			CreateWindowEx(0, TEXT("EDIT"), TEXT(""), WS_CHILD|WS_VISIBLE|ES_MULTILINE|WS_VSCROLL|WS_BORDER, 10, 40, r.right-10-10, r.bottom-10-40, hWnd, HMENU_FROM_CONTROLID(IDC_MYEDITBOX), NULL, NULL);
			CreateWindowEx(0, TEXT("STATIC"), TEXT("Exemple de texte et d'editbox"), WS_CHILD|WS_VISIBLE|SS_NOPREFIX|SS_WORDELLIPSIS, 10, 10, r.right-10-60-10-10, 20, hWnd, HMENU_FROM_CONTROLID(IDC_MYTEXT), NULL, NULL);
			CreateWindowEx(0, TEXT("BUTTON"), TEXT("Bouton"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r.right-10-60, 10, 60, 20, hWnd, HMENU_FROM_CONTROLID(IDC_MYBUTTON), NULL, NULL);
 
			/*Donnons une meilleure police à ces contrôles*/
			{
				NONCLIENTMETRICS ncm = {0};
				HFONT theFont = NULL;
				ncm.cbSize = sizeof ncm;
				SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, &ncm, ncm.cbSize);
				theFont = CreateFontIndirect(&ncm.lfMessageFont);
				SendDlgItemMessage(hWnd, IDC_MYEDITBOX, WM_SETFONT, (WPARAM)theFont, TRUE);
				SendDlgItemMessage(hWnd, IDC_MYTEXT, WM_SETFONT, (WPARAM)theFont, TRUE);
				SendDlgItemMessage(hWnd, IDC_MYBUTTON, WM_SETFONT, (WPARAM)theFont, TRUE);
			}
		}
		break;
 
	case WM_SIZE:
		{
			RECT r = {0};
			GetClientRect(hWnd, &r);
			/*Note: Inutile de passer TRUE ici, grâce à CS_H/VREDRAW.*/
			MoveWindow(GetDlgItem(hWnd, IDC_MYEDITBOX), 10, 40, r.right-10-10, r.bottom-10-40, FALSE);
			MoveWindow(GetDlgItem(hWnd, IDC_MYTEXT), 10, 10, r.right-10-60-10-10, 20, FALSE);
			MoveWindow(GetDlgItem(hWnd, IDC_MYBUTTON), r.right-10-60, 10, 60, 20, FALSE);
		}
		break;
 
	/*Finir la boucle de messages quand cette fenêtre est détruite*/
	/*Note: Pour bien faire, je devrais aussi re-changer la police des contrôles et la détruire.
	  Mais j'ai la flemme et le processus est sur le point de se terminer de toute façon.*/
	case WM_DESTROY: PostQuitMessage(0); break;
 
	default:
		ret = DefWindowProc(hWnd, uMsg, wParam, lParam);
		break;
	}
	return ret;
}
 
int APIENTRY resizing_WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
	HWND hWnd = NULL;
	WNDCLASSEX wcx={0};
	INITCOMMONCONTROLSEX icex = { sizeof icex, ICC_STANDARD_CLASSES };
 
	(void)hPrevInstance;
	(void)lpCmdLine;
	(void)nShowCmd;
 
	/*Initialisation des Common Controls et des Visual Styles*/
 
	InitCommonControlsEx(&icex);
 
	/*Définir la classe de fenêtre*/
	wcx.cbSize = sizeof wcx;
	wcx.hbrBackground = (HBRUSH)(COLOR_3DFACE+1);
	wcx.hInstance = hInstance;
	wcx.lpfnWndProc = resizing_WindowProc;
	wcx.lpszClassName = TEXT("Resizing Window");
	wcx.hCursor = LoadCursor(NULL, IDC_ARROW);
	wcx.style = CS_HREDRAW|CS_VREDRAW; /*Ils semblent être nécessaires en fait, sinon les contrôles se redessinent mal (j'ai l'impression qu'ils se redessinent trop tôt)...*/
	if(RegisterClassEx(&wcx) == 0)
		return EXIT_FAILURE;
 
	hWnd = CreateWindowEx(0, wcx.lpszClassName, TEXT("Fenêtre Redimensionnant ses Contrôles"), WS_OVERLAPPEDWINDOW|WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL);
	if(hWnd != NULL)
	{
		/*Boucle de messages*/
		MSG msg = {0};
		while(GetMessage(&msg, NULL, 0, 0)>0) /*Attente bloquante, dispatche tous les messages 'envoyés' et récupère le premier message 'posté' de la file du thread courant*/
		{
			TranslateMessage(&msg); /*Génère les WM_CHAR à partir des WM_KEYDOWN (les insère en tête de file)*/
			DispatchMessage(&msg); /*Dispatche message récupéré vers la bonne procédure de fenêtre*/
		}
	}
 
	return 0;
}

28/10/2016, 16h16
Médinoc

Pas vraiment besoin de récupérer les dimensions de l'écran, il suffit de créer la fenêtre maximisée (avec le style WS_MAXIMIZE) et ça devrait marcher...
30/10/2016, 12h27
pal1996

Citation:

Médinoc a écrit:

Pas vraiment besoin de récupérer les dimensions de l'écran, il suffit de créer la fenêtre maximisée (avec le style WS_MAXIMIZE) et ça devrait marcher...

J'imagine que le style WM_MAXIMISE sera appelé dans la fonction ShowWindow(). Si c'est le cas ça n'aura probablement pas d'influence sur les dimensions des contrôles juste après leur création. En fait ils dépendront des dimensions par défaut attribuées à la fenêtre (au cas où ils sont créés en fonction de celle-ci). On pourra donc définir les dimensions par défaut à l'aide de getDesktopWindow(); mais vu qu'on aura beaucoup plus de lignes de codes, il serait préférable d'utiliser getSystemMetrics() que mentionnait Mat.M.
Au niveau du code:
- pourquoi utiliser directement des chiffres dans le demensionnement? Je pense que s'il faut faire une fenêtre plus flexible, toutes les coordonnées et dimensions doivent se donner en fonction de la taille de la fenêtre.
- ne serait-il pas mieux déclarer un 'static RECT r' et de l'utiliser dans les différents messages?
- Je n'ai pas remarqué la présence de la fonction ShowWindow(). Qu'est-ce qui la remplace?
30/10/2016, 16h16
Médinoc

Citation:

Envoyé par pal1996

- pourquoi utiliser directement des chiffres dans le demensionnement? Je pense que s'il faut faire une fenêtre plus flexible, toutes les coordonnées et dimensions doivent se donner en fonction de la taille de la fenêtre.

Franchement ça dépend des circonstances. Pour les marges, elles sont le plus souvent fixes (ou du moins, elles ont une valeur minimum). Ici je les ai hard-codées parce que je n'allais pas me compliquer la vie en plus.
Pour les tailles, ça dépend aussi: Un contrôle multi-lignes aura généralement une taille qui dépend directement de celle de la fenêtre, mais un contrôle d'une seule ligne aura généralement une hauteur fixe (même si pour bien faire, il faudrait la faire dépendre de la taille de police plutôt que la hard-coder).

Citation:

- ne serait-il pas mieux déclarer un 'static RECT r' et de l'utiliser dans les différents messages?

Non, parce qu'il n'y a pas de raison que son contenu persiste d'un message à l'autre. Une variable ayant une trop longue durée de vie est source de confusion pour celui qui doit maintenir le code (cad, toi dans six mois)

Citation:

- Je n'ai pas remarqué la présence de la fonction ShowWindow(). Qu'est-ce qui la remplace?

Le style WS_VISIBLE dans l'appel à CreateWindow().

Voir 40 message(s) de cette discussion en une page