Disclaimer. This tutorial focuses heavily on GDI. Many other APIs, OCXs, DLLs and other references you add to your project may also present opportunities for leaking. However, most of the leaks we experience are those we created via GDI and GDI+ API calls. Therefore, focus has been set on GDI.
I have organized some of my thoughts and have tried to, as compactly as possible, provide many years of experience with finding leaks, into a short, step by step process. As with most potential problems, prevention is less painful than the cure. The first Section of this five-part document is a list of what I consider the best coding practices to preventing leaks in the first place. I think that if you have little experience tracking down leaks in your application, the following will help. There are other more complicated methods to help resolve leaks which include memory dumps and other more advanced techniques. I do not claim to be that smart, what I offer here is a commonsense, and somewhat easy and free, approach to dealing with the leaky situation.
A leaky application is a sure way for your application to lose all credibility with the user. Even worse, you, as a coder, may lose hard-earned credibility. I personally take pride in providing “leak-free” code. However, we all make mistakes, and the information within this document can help you correct those mistakes - it has helped me more times than I can remember and continues to.
DEFINITIONS
API. Application Programming Interface (DLL) Clean Up. Code used to destroy created objects, freeing memory back to the system DC. Device Context GDI. Graphics Device Interface (DLL) IDE. Visual Basic's Integrated Development Environment. Leak. Used or reserved memory that has not been freed and not returned to the system.
Reply With Quote