Subclassing - need to revert to old proc?

[jj2007]

I have searched MSDN for a clear answer, but they are not very explicit about whether apps must/should/can restore the original procedure on WM_DESTROY (or WM_CLOSE??). Is there a non-ambiguous answer? As far as I can see, in the moment when the app kills the child control, there will be no more attempts to access the code, so no need to restore the old one...

However, the MSDN subclassing example does it:

Code Select Expand

invoke SetWindowLong, hwndEdit, GWL_WNDPROC, pOrigEditProc

[donkey]

It is needed because in some cases because of the heavy recursion involved in destroying windows, a window can already be destroyed when WM_NCDESTROY is returned, in that case the instance handles have already been discarded (along with the window) and the WM_NCDESTROY message uses what amounts to garbage on the heap as an instance handle with the predictable result of a C0000005 error (ACCESS_VIOLATION). It should be noted that this is an extremely rare occurance, it generally only happens with a child window with multiple child windows integrated within it, for example a listview, however it is a real possibility.

Donkey

[hutch--]

jj,

Safety wise you should always create the subclass again when you create a new window. A dead window (destroyed) may still have the old proc in memory somewhere but its a dangerous practice as it could be overwriten by something else.

If the window is still running and you want the old message proc for it after subclassing it, just save the value and reset it back again. A subcl;ass is only ever a bypass of the original proc where you can return zero or do the default processing after your subclass.

[jj2007]

Thanxalot. My proggies have simple collections of buttons and statics, so I suppose it's safe to let them die naturally - but your warning about "garbage on the heap" is taken seriously. I'll watch out for error C0000005  :bg