 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Pocket PC Forum / Developers / WinCE Programming / July 2008GDI Resources and DeleteObject( )
** Embedded Visual C++ 4.0 / WinCE 5.0 ** When I create CFont, CPen, CBrush objects in a function, do I need to call the DeleteObject( ) method when done, or is this done in the object's destructor? The documentation is inconsistent. Are there some GDI objects that require it and others that do not? I am dealing with an unexplained slow increase in memory load, but nothing is being reported as a leak in CodeSnitch. I am trying to eliminate this as a possibility. Thank you, - eepcat Don't you have the source for MFC? It should be in the MFC subdirectory of the SDK install folder for the SDK you are targeting with your application. It appears to me that any subclass of CGdiObject calls DeleteObject() in the destructor. CPen is such a subclass. Paul T. > ** Embedded Visual C++ 4.0 / WinCE 5.0 ** > [quoted text clipped - 10 lines] > Thank you, > - eepcat Hi Eepcat, CodeSnitch doesn't track all memory usage. There is a list of APIs listed in the Reference help section. Notably missing are things like Oleauto things, COM objects (especially ones in OS such as msxml), winsock and other handle types. Are you testing a release build of your application? Is so, check this FAQ: http://www.entrek.com/FAQ.asp#33. It actually addresses a different problem (where it reports false leaks), but a lot of MFC devs run into this eventually so worth checking out.  SignatureMichael Salamone, eMVP Entrek Software, Inc. www.entrek.com > ** Embedded Visual C++ 4.0 / WinCE 5.0 ** > [quoted text clipped - 10 lines] > Thank you, > - eepcat Thank you for the replies. I am running a debug build, so the retail issue is not of concern. Thank you for pointing that out, though - it's good to know. I've been over the code a hundred times and do not think this is a GDI leak. I'm going to shift to Application Verifier and look for any memory corruptions. Thanks again, - eepcat > Hi Eepcat, > [quoted text clipped - 22 lines] > > Thank you, > > - eepcat Btw one other thing to be aware of w/CodeSnitch is that it only tracks memory in instrumented modules. It will auto-instrument any DLLs your application is linked to, but if you have any that are loaded dynamically via call to LoadLibrary or CoCreateInstance, then you need to manually those to the instrumentation list. Otherwise if they are leaky, CodeSnitch won't be able to detect and report that. Click the "Dependencies..." button on the Run dialog to add those DLLs to the instrumentation list. Incidentally CodeSnitch has help with heap corruption, too. Click the "Runtime Options..." button to turn control enabling/disabling of those features and others. SignatureMichael Salamone, eMVP Entrek Software, Inc. www.entrek.com > Thank you for the replies. I am running a debug build, so the retail > issue [quoted text clipped - 41 lines] >> > Thank you, >> > - eepcat Thank you. I found the cause of the leak... http://support.microsoft.com/kb/839859 CE Temporary GDI objects not being cleaned up in background. You learn something new every day :-) Thanks for all the help, - eepcat > Btw one other thing to be aware of w/CodeSnitch is that it only tracks > memory in instrumented modules. It will auto-instrument any DLLs your [quoted text clipped - 53 lines] > >> > Thank you, > >> > - eepcat |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.