Questions about subcalssing

[MichaelW]

In a window procedure that calls external functions, the prologue and epilogue overhead should be insignificant.

[ToutEnMasm]

It is said here
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/11/55653.aspx
"you must remove your window subclass before the window being subclassed is destroyed"
Is it true ?

[jj2007]

"you must remove your window subclass before the window being subclassed is destroyed"
Is it true ?

If it's a thread, one could try to find scenarios where this might cause trouble. If the process is about to end, no I can't imagine that not un-subclassing could have any effect. But there are some people here who have a much deeper understanding of Windows internals - and I also find that question interesting.

[ToutEnMasm]

"you must remove your window subclass before the window being subclassed is destroyed"
Is it true ?

No answer ?..
One post say:

If you subclassed with the SetWindowSubclass function, then you need to unsubclass to clean up the bookkeeping that SetWindowSubclass created for you. If you are running a chk build, you will break into the debugger with an error if SetWindowSubclass detects that a subclass failed to clean itself up. If you subclassed manually via SubclassWindow then you're on your own to to clean up whatever bookkeeping you have attached to the subclass. If you have no bookkeeping that needs to be cleaned up, then you're home free.

If it is only a problem with the check build,no matter,masm don't use it.
If there is a risk to let allocated memory ,it is annoying.But this isn't refered in any windows help files.

[hutch--]

Convenrtional subclassing has never had the problem, if you destroy the Window then there is no callback for that window to be subclassed. The code will still be in memory as it is part of the application but it is dead until it is re-used again. Think of what a subclass is, a user defined bypass that gains access into the message handler for a pre-defined window that already has its own class. This is why you need the address of the original message handler to pass control back to it.

[ToutEnMasm]

I have made some tests with the crt debug functions who detects memory leaks and more.
Results are almost obvious.
There is no need to call the RemoveWindowSubclass until we don't pass allocated memory to the subclass procédure.
In this case (the dwRefData is used) , the close of the subclass is needed before freed of the allocated memory.Those to avoid read write operations in a freed memory.
That all.