Re: Leaking GDI resources
Not to say that I'm using MS VC++ and the plain vanilla API.
Re: Leaking GDI resources
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.
Re: Leaking GDI resources
Quote:
Originally Posted by
oldnewbie
Any suggestion would be appreciated.
If you read about LoadImage Function in MSDN, you'd see:
Quote:
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
Re: Leaking GDI resources
Quote:
Originally Posted by
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.
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.
Re: Leaking GDI resources
Could be either. Although, I don't know why you're moving windows from within a WM_PAINT handler. That sounds odd.
Re: Leaking GDI resources
Quote:
Originally Posted by
VladimirF
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 :-)
Re: Leaking GDI resources
Quote:
Originally Posted by
hoxsiew
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.