Leaking GDI resources

[oldnewbie]

Hi all:

I have an application who uses some BS_OWNERDRAW style buttons, and in the dialog-procedure, some like this to draw them:

case WM_DRAWITEM:
{
LPDRAWITEMSTRUCT pdis = (LPDRAWITEMSTRUCT) lParam;
HICON hIcon = (HICON)LoadImage (mhok.hInstance, MAKEINTRESOURCE(idButton), IMAGE_ICON, 0,0, LR_DEFAULTCOLOR|LR_LOADTRANSPARENT);

DrawIconEx (pdis->hDC, 0, 0, hIcon, 0, 0, 0, NULL, DI_NORMAL);

// The doc. states: If an application processes this message, it should return TRUE.
return TRUE;
}

The problem is that after running a while, the application behaves badly.

After diggin a bit in Google -in the Forger's Win32 API Programming Tutorial- I have found: "If your program runs fine for a few minutes and then starts drawing strangely or not at all, it's a good sign that you're leaking GDI resources".

Besides that, referring to the WM_DRAWITEM message, the MS doc state that: "Before returning from processing this message, an application should ensure that the device context identified by the hDC member of the DRAWITEMSTRUCT structure is in the default state".

The question is: How can I ensure that the pdis->hDC member is in the default state?

May be including

RestoreDC (pdis->hDC, -1);

before the return?

Or perhaps

ReleaseDC(pdis->hwndItem, pdis->hDC);

in that place?

Any suggestion would be appreciated.

[oldnewbie]

Not to say that I'm using MS VC++ and the plain vanilla API.

[hoxsiew]

RestoreDC() can be used, but it must correspond to a SaveDC() call at the beginning of your paint routine. It would help to see the code for your paint routine as a leaking GDI resource should be readily apparent.

[VladimirF]

Any suggestion would be appreciated.

If you read about LoadImage Function in MSDN, you'd see:

Remarks
When you are finished using a bitmap, cursor, or icon you loaded without specifying the LR_SHARED flag, you can release its associated memory by calling one of the functions in the following table.

Resource Release function
Bitmap DeleteObject
Cursor DestroyCursor
Icon DestroyIcon

[oldnewbie]

RestoreDC() can be used, but it must correspond to a SaveDC() call at the beginning of your paint routine. It would help to see the code for your paint routine as a leaking GDI resource should be readily apparent.

hoxsiev:

Because my WM_PAINT message treatement include several routines -basically to move windows- and prior to any further investigation, do you suggest that the memory leak is in the process of this former message more that in the WM_DRAWITEM as I was suspecting?

Thank for your input.

[hoxsiew]

Could be either. Although, I don't know why you're moving windows from within a WM_PAINT handler. That sounds odd.

[oldnewbie]

If you read about LoadImage Function in MSDN, you'd see:

VladimirF:

I just add the LR_SHARED condition to my LoadImage functions, and although I've made just a quick pair of tests, the good old Task Manager suggest that you shot directly in the bull's-eye.

Thank you very muuuuch for your quick response :-)

[oldnewbie]

Could be either. Although, I don't know why you're moving windows from within a WM_PAINT handler. That sounds odd.

hoxsiev:

Indeed it is. It's just the result of a newbie design and probably a poor solution to scroll the content of a dialog box who can grow and shrink in size -i.e can include a variable number of elements, without the use of the standard scroll bars. Yes I know, it sounds brutal but do the work.