from http://delphi.about.com/od/windowsshellapi/l/aa111503d.htm
in the WM_DESTROY Msg use PostQuitMessage(0) to end the GetMessage loop, so Windows can clean up. When the WM_CLOSE message is sent to the DefWndProc it calls DestroyWindow for that window. When the DestroyWindow is called, a WM_DESTROY message is created, then the window and all of its children are destroyed. This releases the window's system memory used to record its properties (handle, width, height, position, Window Proc, style, children, and many others). If DestroyWindow is not called, then this memory with the objects properties remains until the system is restarted. Avoid this type of memory leak if possible. If you have a critical error and must Halt the execution, at least try to call DestroyWindow(hForm1) for your main window. WndMessageProc function, the "Window Proc" The WndMessageProc function in the program code below, can determine what is displayed on screen for our program's client area and how this program responds to user and system input. I have used the function name of "WndMessageProc" just to show you that you do not have to call it "WndProc", as many code examples seem to imply. reid -----Original Message----- From: Mark Wyszomierski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 15, 2005 3:35 PM To: Reid Thompson Cc: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: Re: [sqlite] tracing memroy leak I traced this error down a bit, it only appears when using windows' PostMessage() to communicate between applications. Both applications have their own database handles for sure. When one app gets some data, it simply uses PostMessage() to inform the other app that some data has been received. It is at this point that if I try accessing the database in this message handler, the memory leak occurrs. I even took the additional precaution of creating an entirely new database handle inside the message handler itself. If I replace PostMessage() with SendMessage(), no leak occurrs. However, replacing PostMessage() with SendMessage() would be a huge penalty. Any ideas why there is a problem here? Thanks, Mark On 9/15/05, Reid Thompson <[EMAIL PROTECTED]> wrote: Jay Sprenkle wrote: > The premier analysis tool that I know about is valgrind: > http://valgrind.org/info/about.html splint may be of interest also http://www.splint.org/ reid