I recently downloaded MemProof to test for memory leaks. So I run it on a program I'm making and it tells me after I close my program that I didn't destroy 2 windows. The layout of my program is one parent window and 4 child windows.

After some work I find that the two windows are a listbox and the parent window. To fix the problem I had to put the following two lines in my WM_DESTROY handler of my parent window:

@@Destroy: invoke DefWindowProc,hWin,uMsg,wParam,lParam
invoke DestroyWindow,hListWnd

followed by the PostQuitMessage,etc.

The thing that gets me is this:
a) shouldn't the List box be destroyed as all the other children were, sort of automatically?
b) Why should I have to call DefWindowProc to completely destroy the parent (I've never seen this documented)

Any insight is appreciated


PS, here's how I create the list box in case someone sees something fishy:

addr szListClassName,
mov hListWnd,eax
Posted on 2002-07-20 23:27:28 by chorus
Have no experience with MemProof yet, but its behaviour looks strange.
Don't know why MemProof tells you about not closing windows, but i guess the problem is that MemProof has no asm compilers support.

From API ref:
The WM_DESTROY message is sent...

This message is sent first to the window being destroyed and then to the child windows (if any) as they are destroyed. During the processing of the message, it can be assumed that all child windows still exist.

If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.

Obtaining WM_DESTROY message means that Windows already has called DestroyWindow for your parent window.

As i can see from CreateWindowEx your listbox is child of your main window (hWin).
So it destroys automatically. And you shouldn't explicity destroy your childs.

You shouldn't put DefWindowProc in WM_DESTROY processing:
The DefWindowProc provides default processing for any window messages that an application does not process.

If listbox is sub/superclassed, check its WM_DESTROY branch.
Try to test MemProof with very simple ex - one owner and only one child window.
Posted on 2002-07-21 14:47:03 by Four-F

I wouldn't trust MemProof too much; from what I've read in it's help, it was design to test leaks in Delphi programs.
Besides, I didn't like it it too much, Numega BoundsChecker is better ;-)

Considering your code, I took a straightforward approach and tested it in BC (BoundChecker)
Merely inserted your CreateWindowEx for ListBox in WM_CREATE handler.
No extra s**t was done in WM_DESTROY handler, only what Procstart puts there, i.e.
invoke PostQuitMessage, NULL

All went smooth (as it should be) upon exit Program being tested in BC.
No errors, etc.

So again, summarizing, i think that MemProof is not very well suits regular programs based on WinAPI calls, it is better for Delphi-bloatwares... ;-)
Posted on 2002-07-21 15:27:29 by Andycar
I've downloaded MemProof and played a bit with it.

In one case i loaded icon with LoadIcon func and then sent WM_SETICON to set it to dialog.
And MemProof told me that:
The returned icon handle must be freed with DestroyIcon when no longer needed.

But in API reference i read:
It is only necessary to call DestroyIcon for icons created with the CreateIconIndirect function.

In other case i used CreateMenu/SetMenu to assign menu to window.
And MemProof told me that:
The returned menu handle must be freed with DestroyMenu when no longer needed.

But API reference tells me that:
A menu that is assigned to a window is automatically destroyed when the application closes.

Every time i call CreateWindowEx to create some window MemProof reports me stupid:
The returned window handle must be freed with DestroyWindow or by passing a WM_DESTROY message to the default window procedure.

And so on....
So, IMHO, you shouldn't believe it much.
Posted on 2002-07-21 15:50:56 by Four-F
Four-F, I'm beginning to think that all MemProof does is count how many times you call, say, LoadIcon and how many times you call the DestroyIcon proc. But as you pointed out, the win32api and MSDN say you don't need to call DestroyIcon unless you call CreateIconIndirect.

However, I thought the strangest thing was that all my other child windows were being (reported as) destroyed but the list box wasn't. It wasn't subclassed either...

Whatever... I guess I'll just watch for "important" things like GlobalAllocs, etc.

Andycar, I'll take a look into BoundsChecker. Thanks for the idea :)

Thanks again guys
Posted on 2002-07-21 16:20:30 by chorus