Discussion :

[LittleWhite]

Bonjour,

J'espère que je suis sur le bon forum ... ce n'est pas souvent que je vais de cette sous catégorie .

Aujourd'hui j'utilise la fonction GetDC(hWnd). Il n'y a pas de mal à ça, sauf que j'ai des problèmes avec. Voulant vérifié les valeurs que cela me retourne, j'affiche la valeur de HDC, qui ... change à chaque appel de GetDC().
Ok, je prends un bouquin sur la programmation pour windows ( ou truc qui se trouvait dans le coin, et qui remonte à Windows95 ) et je lit:
"
L'utilisateur n'a pas à s'occuper de la valeurs des HANDLE (car HDC est un HANDLE). Les fonctions de Windows seront comment traité le HANDLE
"

Oui, bah pourquoi pas, dans la théorie cela ne me gêne pas du tout. Mais lorsque l'on débuggue, c'est comme même très décevant comme information ( et puis je suis curieux ).
Donc je voudrais savoir d'une part:

1. Comment la fonction HDC peut renvoyer toujours une valeurs différentes ( pointant/désignant sur le même objet ) ( est ce un pointeur qui est retourné? )?
2. Comment font les fonctions de Windows pour traiter les informations d'un HANDLE? cast?

Merci pour vos futures réponses

[ram-0000]

Un handle est un objet Windows que l'on n'a pas à connaitre. Windows le gère très bien.

Maintenant, sous le capot, je dirais que c'est effectivement un pointeur sur une structure opaque allouée par Windows (c'est mon avis, je ne suis pas développeur chez Microsoft, mais c'est comme cela que je ferais si j'avais à le faire).

Je viens de voir ceci dans <winnt.h>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef void *HANDLE;

Que tu recoives une valeur de handle différente sur chaque GetDC() n'est pas très surprenante. Sur un GetDC(), Windows va allouer une structure gérée par le GDI et va te donner un pointeur sur cette structure que tu pourras redonner au GDI afin de référence la bonne structure.

Après, sous le capot, il y a probablement des cast pour transformer ces HANDLE en pointeur sur les bonnes structures.

[sevyc64]

De manière générale, un handle est un identifiant unique permettant d'accéder à une instance particulière d'un object.

Revenons sous Windows, un handle est donc généralement un pointeur vers une zone mémoire qui contient, soit l'objet lui-même, soit une structure permettant d'identifier et de qualifier l'objet quelle représente.


Et c'est vrai que l'on n'a pas à se soucier du handle, c'est le coeur du système Windows qui s'en occupe. D'autant que sous Windows les objets, variables, etc, sont très volatiles et mobiles. Une variable par exemple est stockée en mémoire durant son utilisation, mais celle-ci peut changer plusieurs fois d'emplacement mémoire durant sa durée de vie.

Windows gère très bien tout ça, et il ne faut pas s'étonner de voir les handles être modifier en 2 appels.

[sloshy]

Bonjour,
Un handle n'est en aucun cas un pointeur.
un handle est un ID identifiant de maniere unique un objet windows, il s'agit d'un simple nombre

EDIT://
On peut trouver ceci dans la FAQ
PS: je doute qu'un livre d'un windows 16bits soit encore d'actualite

[LittleWhite]

Je suis désolé, mais pour le fait que le HANDLE soit un ID, j'ai un peu de mal. Certes le nom du type le laisse penser, sauf que, si je fait le code suivant;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
printf("ID: %d",(unsigned int)GetDC(NULL));
printf("ID: %d",(unsigned int)GetDC(NULL));

// Ou même

printf("ID: %d",(unsigned int)GetDC(fenetere_valide));
printf("ID: %d",(unsigned int)GetDC(fenetere_valide));

Si c'était un simple ID, la valeur serait deux fois la même, mais avec un tel code, j'ai eu des valeurs différentes.
Et ce n'est pas non plus un pointeur sur un unsigned int... car l'accès a une valeur pointé après cast crash le programme.

Après, je suis entièrement d'accord, je n'ai pas besoin de savoir ce que c'est réellement, mon système va géré tout ça ... mais je me demandais par curiosité, et aussi pour savoir comment un pilote graphique, qui voudrait faire un rendu sur un HDC ... utiliserai les informations du HDC ... alors que l'on a que l'accès limité de la Windows API.

Mon livre parlait du 32bits de toute façon :p

Après, si c'était un bête pointeur ... je ne comprendrais pas pourquoi la valeurs change entre deux appels. Je veux dire, la valeur pour pointer sur une variable fixe est toujours la même.

(J'avais trouvé la référence dans winnt.h aussi)

[sloshy]

le chapitre Object Manager de Windows Internals te donnera toutes les info dont tu as besoins

[Melem]

Un handle est un numéro qui sert à identifier un objet sous Windows, un ID donc. Pour l'exemple avec GetDC, c'est simple : GetDC crée un DC et retourne le handle de ce DC. Avec GetDC(NULL), tu as donc au final deux DC différents, chacun ayant son ID, bien que tous les deux soient associés à un même et unique préiphérique : l'écran (Windows XP/2003 et <) ou la surface D3D qui gère l'écran (Windows Vista et >), selon ton système. Pareil avec GetDC(fenetre_valide).

Un type "handle" est systématiquement un typedef d'un type pointeur (dans le cas de HANDLE, c'est un typedef de void *), mais ça ne signifie pas qu'un handle est un pointeur. Mais il peut effectivement être un pointeur.

[FAQ] Un handle est-il un pointeur ?

[LittleWhite]

D'accord.

Donc mon HANDLE est un ID. GetDC ou autre fonction ( je pense à GetHWND ) vont crée à chaque fois, un HANDLE différent, mais qui correspond toujours au même objet.
Ah ... mince, non c'est pire que ça ... c'est que Windows crée un DC à chaque fois ... alors faudrait t'il que je free tout les HANDLE retourné par GetDC?

J'ai un peu de mal à saisir l'objectif des developpeurs chez Microsoft, de dire on va crée à chaque fois un HANDLE différent ... mais pourquoi pas ... O_o

Et du coup, en interne, comment fait Windows pour pouvoir utilisé ses HANDLE ... j'imagine que cela marche comme une liste ( ou une map ) et qui en cherchant l'ID nous avons l'objet.

[Médinoc]

Déjà, d'autres infos sur les différents types de handles et les possibles utilisations du type HANDLE lui-même.

Ensuite, pour répondre à ta question:
Oui, il faut que tu libères tous les handles retournés par GetDC(). C'est à ça que sert la fonction ReleaseDC(). Par contre, Windows utilise un pool pour ses DCs de fenêtre (ceux retournés par GetDC() ou BeginPaint()), tu n'as donc pas à te soucier de la performance... si tu penses à rendre les DCs quand tu n'en as plus besoin.

[LittleWhite]

Ensuite, pour répondre à ta question:
Oui, il faut que tu libères tous les handles retournés par GetDC(). C'est à ça que sert la fonction ReleaseDC(). Par contre, Windows utilise un pool pour ses DCs de fenêtre (ceux retournés par GetDC() ou BeginPaint()), tu n'as donc pas à te soucier de la performance... si tu penses à rendre les DCs quand tu n'en as plus besoin.

Et bah là j'ai comme une grosse fuite de mémoire ...
Si je puis me permettre ... je trouve ça pourri comme façon de faire une bibliothèque ... mais ... je ne dois pas dire ça ...

Merci pour toutes les informations ...

[Médinoc]

Si je puis me permettre ... je trouve ça pourri comme façon de faire une bibliothèque ...

Pourquoi?

Pour moi, c'est le même genre d'abstraction qu'un FILE* ou un descripteur de fichier POSIX...

Sauf qu'un pointeur bidon est mieux qu'un int, parce que ça réduit les opérations arithmétiques qu'on peut faire dessus, et avec les handles on n'est censé en faire aucune...

[LittleWhite]

Je m'explique un peu mieux, au lieu de critiquer à tort et à travers ( je m'en excuse ).

Dans mon code tout pourri ... j'appelle GetDC() à chaque fois que j'ai besoin du HDC de ma fenêtre. Et je ne le stocke jamais ( problème de conception, c'est sur ). Mais je ne faisais jamais de ReleaseDC dessus non plus ( alors là, y a un vrai problème ).
Pour moi, comme j'avais toujours le même HWND, je pensais qu'il me retournerai toujours le même HDC ... mais là, je viens d'apprendre que non ... la WinAPI recrée un objet à chaque fois ... et que bien sur, même si celui là correspond toujours au même objet, il faut le libéré ...
Donc, je confirme mes propos, je trouve ça assez bancal, que d'avoir une fonction qui crée à chaque fois un objet, même si cet objet pointera toujours sur la même chose.
Et puis j'espère que lorsque je ferai le ReleaseDC, il ne va pas rendre mon HWND invalide ( normalement non, enfin je ne pense pas ).

[Médinoc]

Ce que tu n'as pas compris, c'est que les DCs ne sont pas associés de manière permanente à une fenêtre; en fait, il y a un "pool" d'environ cinq DCs (au début) qui sont "attachés" à une fenêtre quand on en demande un.

En gros, GetDC() ne retourne pas le DC de ta fenêtre mais un DC pour ta fenêtre. Les DCs sont une ressource partagée, il faut donc les demander et les rendre.

Mais dans tous les cas, les DCs ne sont pas "créés" à chaque appel, sauf bien sûr quand il n'y a plus de DC libre dans le pool.

PS: Normalement, tu ne devrais même pas avoir à utiliser GetDC() et ReleaseDC() : Si tu ne "dessines" dans la fenêtre de dans le traitement de WM_PAINT, tu reçois le DC via BeginPaint() et EndPaint()...
(quant à WM_PRINTCLIENT, il te passe le DC en paramètre)

[LittleWhite]

PS: Normalement, tu ne devrais même pas avoir à utiliser GetDC() et ReleaseDC() : Si tu ne "dessines" dans la fenêtre de dans le traitement de WM_PAINT, tu reçois le DC via BeginPaint() et EndPaint()...
(quant à WM_PRINTCLIENT, il te passe le DC en paramètre)

Oui bien sur ... mais je suis loin d'être dans le cas "normal".
Effectivement, je n'utilise pas la boucle d'évènement, enfin pas à proprement parler. Après pour expliciter un peu ... j'ai besoin de ce HDC, pour EGL ( c'est un truc pour OpenGL )... et bon ... comme j'ai fais un truc faux dans mon programme ... je dois récupéré le HDC à chaque appel d'une fonction EGL ( et oui ... je suis parti vraiment sur un truc faux ... )
Donc je corrige ça et mon problème sera réglé.

Merci pour toutes les explications sur le HANDLE

[minnesota]

Bonjour,

Donc je voudrais savoir d'une part:

1. Comment la fonction HDC peut renvoyer toujours une valeurs différentes ( pointant/désignant sur le même objet ) ( est ce un pointeur qui est retourné? )?
2. Comment font les fonctions de Windows pour traiter les informations d'un HANDLE? cast?

Ram-0000 a bien résumé la situation avec des termes de programmeurs pour programmeurs. Les trois premiers paragraphes de sevyc64 sont également très explicites.

HDC n'est pas une fonction, c'est un type!!! Un type de donnée Windows.
HDC est le diminutif de Handle Device Context, en français on dirait que c'est une "poignée sur un contexte de périphérique", en l'occurrence un contexte de carte vidéo ou d'imprimante. Je m'arrête un instant sur le terme Handle très ambigu, parce qu’ambivalent.

En effet, ce dernier représente à la fois un concept, celui d'obtenir une "poignée" pour pouvoir agir sur un service rendu par le système d'exploitation, mais aussi un type, en l'occurrence le type HANDLE (en majuscule) qui s'avère en plus être défini comme étant un pointeur. Pas n'importe lequel, un "void pointer", ce qui est lourd de sens. Mais peu importe, même si tous les types de Handles sont des "void pointers", donc des HANDLE (exception faite de HFILE ("Handle to a file" ou "file Handle" qui est un INT) et HRESULT ("result handling" qui est un LONG) considérait parfois à tord comme un Handle), ils sont avant tout faits par Windows pour Windows.

Pour schématiser, Windows offre des services (au sens littéral du terme, donc à ne pas confondre avec leurs homophones exécutables qui travaillent en tache de fond) et des fonctions pour appeler et agir sur ces mêmes services.

Concrètement, on témoigne auprès de Windows de notre intention d'utiliser tel ou tel service avec une des fonctions d'appels appropriées, ce dernier répond en retournant un Handle (usuellement différent de 0) s'il est apte à rendre ce service, en l'occurrence si tous les mécanismes sous-jacents pour sa mise à disposition ont réussi. Pour certains services, on peut lancer plusieurs instances d'un même service, et chaque Handle retourné sera ainsi différent.
Ensuite, on peut agir ou interagir avec une instance de ce service, à l'aide des fonctions qui lui sont dédiées et en utilisant en paramètre le Handle qui lui est propre. Dans ce contexte, le Handle fait office d'identifiant. Windows l'utilise en interne pour se référer au descripteur de l'instance du service à chaque fois que l'on réalise une action sur ce dernier.
Il y a Handle et Pseudo-Handle. La différence réside dans le fait que le Handle est global (il est accessible à n'importe quel processus autorisé), à l'inverse, le Pseudo-Handle est accessible uniquement au processus qui en est à l'origine. Enfin, une fois qu'on a plus besoin du service, on en informe le système d'exploitation avec les fonctions adéquates et cela entraine la fermeture du Handle, l'instance du service n'est donc plus accessible.

La raison pour laquelle on traine toujours cet Handle en paramètre de fonctions est due au fait que l'API Windows est programmé en langage "C". Cela n'empêche pas des "Wrappers" de l'API de rendre la chose un peu plus abstraite et donc plus simple pour l'utilisateur.

Enfin, parmi les services que peut rendre Windows certains sont très concrets et se rapprochent fortement d'une entité que l'on pourrait considérer comme physique, par exemple le service de gestion du curseur. Ainsi, il est assez commun de considérer, dans ce type d'exemple, le curseur (représenté en interne par un Handle de type HCURSOR (Cursor Handle)) comme étant un objet, mais il faut bien garder à l'esprit que c'est un objet système et non un objet au sens "Programmation Orienté Objet" même si dans certaines librairies il peut être géré comme tel. Voilà pour l'histoire du Handle.

Revenant maintenant à la fonction GetDC() et à sa Lib GDI.
Concrètement, il s'agit d'un des services permettant au programmeur de dessiner, mais pas que.
GetDC() est une des fonctions d'appel, qui lorsqu'elle aboutit, retourne un HDC (Handle Device Context).
Elle s'utilise de la manière suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
HDC hdc;
...
hdc = GetDC(hwnd);
...
fonction(s) de dessin GDI...
...
ReleaseDC(hwnd, hdc);

Faire un appel GetDC() revient en fait à demander à Windows un "Device Context". Schématiquement, ce peut être vu comme une feuille de papier vierge, ou un calque, sur laquelle ou lequel on a en général l'intention de dessiner. Si on appelle plusieurs fois GetDC(), on obtient plusieurs feuilles, c'est-à-dire plusieurs "Devices Context", plusieurs HDC, donc plusieurs Handles différents. Grâce au Handle qui est propre à chaque feuille (HDC), on peut dessiner sur la feuille de son choix avec des fonctions GDI. On peut aussi fusionner des feuilles, faire des zooms, et plusieurs autres choses. Une fois que l'on a plus besoin d'une feuille, on n’oublie surtout pas de prévenir le système, ici, via la fonction jumelée de GetDC(), en l'occurrence ReleaseDC().

Voilà, j'ai essayé d'être à la fois complet et succinct, mais ce n'est pas évident de marier deux aspects antagonistes. J'espère en tout cas que ce résumé aidera à mieux appréhender la programmation Windows.

Cordialement.

[LittleWhite]

Merci beaucoup pour cette explication.

Note trollesque: Je n'aime toujours pas la programmation avec Windows.
/Fin de la note
Mais je vais faire de mon mieux pour que mon programme ne fuit pas trop ... et puis maintenant je sais exactement le pourquoi il retourne toujours un truc différent.

Donc merci à vous tous