Bonjour,
J'aurais une question, si vous voulez bien m'aider, qui porte sur les objets gdi créés via l'api windows CreateSolidBrush.
Pour info préliminaire (si ça change quelquechose mais je ne pense pas) j'ai choisi de réaliser ce projet en C (/TC).
Donc,
dans le très instructif exemple de racpp (merci :) sur la transparence et les couleurs des contrôles, racpp déclare et instancie ses HBRUSH dans le CALLBACK de sa fenêtre principale de la sorte :
Code C/C++ :
BOOL CALLBACK DialogProc( HWND hDlg, UINT message, WPARAM wParam,LPARAM lParam )
{
static HBRUSH hbDialog = CreateSolidBrush(RGB(200,175,100));
...C'est très pratique, je connaissais l'utilisation du préfixe 'static' pour les méthodes en cpp mais pas pour les variables.
Après 2 ou 3 tests je pense avoir compris que ça permet de ne l'initialiser que lors du premier appel.
Bon, comme mon projet est en C je ne fais pas comme ça, je déclare les HBRUSH en global et je les initialise lorsque la fonction CALLBACK de ma fenêtre principale reçoit le message WM_INITDIALOG (elle ne reçoit pas le message WM_CREATE comme je passe par DialogBoxParam pour la créer).
Ca fonctionne très bien.
Mais,
voilà, je voudrais créer mes HBRUSH en fonction de certains paramètres dynamiques. Je fais ça via CreateSolidBrush :
Code C/C++ :
HBRUSH hBrush;
//...et plus loin...
hBrush= CreateSolidBrush(RGB(r,g,b));
Seulement lorsque le HBRUSH vient à changer et que j'en recrée un autre, je n'arrive pas à libérer le précédent.
-
DeleteObject((HGDIOBJ)hBrush) -> renvoie systématiquement NULL
-
DeleteObject(SelectObject(???,hBrush)) -> je ne sais pas quoi mettre à la place des '???' vu qu'il s'agit d'un controle en ressource, et avec sont handle ça ne fontionne pas non plus
Je me retrouve donc avec une dramatique fuite d'objets gdi qui fait rapidement péter la limite des 9999 et qui fait donc bugguer l'application.
L'un d'entre vous saurait'il comment faire svp ?
J'imagine que c'est du déjà vu mais je n'ai pas trouvé.
Merci d'avance.
@+