Apr 21st, 2017, 09:24 AM
I've spent the last few days integrating all this stuff into my primary project, and I'm VERY pleased.
Here's the extended list of notes (at the top of my subclassing module) that I've put together.
I've zipped and attached my entire subclassing module for anyone who wants to take a look at it (although there are a few dependent functions someone would have to work out to actually use it). I'm still considering one additional "tweak" but I'll start a new thread to discuss it.
' Notes on subclassing with Comctl32.DLL:
' 1. "Each subclass is uniquely identified by the address of the pfnSubclass and its uIdSubclass"
' (quote from Microsoft.com).
' 2. For a particular hWnd, the last procedure hooked will be the first to execute.
' 3. If we call SetWindowSubclass repeatedly with the same hWnd, same pfnSubclass,
' same uIdSubclass, and same dwRefData, it does nothing at all.
' Not even the order of the hooked functions will change,
' even if other functions were hooked later, and then SetWindowSubclass was
' called again with the same hWnd, pfnSubclass, uIdSubclass, and dwRefData.
' 4. Similar to the above, if we call SetWindowSubclass repeatedly,
' and nothing changes but the dwRefData, the dwRefData is changed like we want,
' but the order of execution of the functions still stays the same as it was.
' "To change reference data you can make subsequent calls to SetWindowSubclass"
' (quote from Microsoft.com).
' 5. When unhooking, we can call RemoveWindowSubclass in any order we like, with no harm.
' 6. We don't have to call DefSubclassProc in a particular hooked function, but if we don't,
' all other "downstream" hooked functions won't execute.
' 7. In the hooked function, if uMsg = WM_DESTROY we should absolutely call
' DefSubclassProc so that other possible "downstream" hooks can also unhook.
' 8. A hooked function will get executed even AFTER the IDE "Stop" button is pressed.
' This gives us an opportunity to unhook everything if things are done correctly.
' 9. All COM objects are un-instantiated BEFORE the hooked functions are
' called with "uMsg = WM_DESTROY" when the "Stop" button is pressed.
' This would include any Collections. It seems similar to executing code in
' the Immediate window. So, we can't reference any COM code, and we can't
' instantiate anything. We must keep this in mind if we wish to be IDE "Stop" button safe.
' Error trapping CAN be used to keep us out of trouble regarding this.
' 10. Dynamic arrays are gone too when "Stop" is clicked. However, static arrays, and both
' Public and Private non-array variables are still accessible. This is more to keep in mind
' to stay IDE "Stop" button safe.
' 11. The END statement still wipes us out (IDE crash), so just don't use it.
' Apparently, it's even more abrupt than the IDE "Stop" button.
' 12. The dwRefData can be used for whatever we want. It's stored by Comctl32.DLL and is
' returned everytime the hooked procedure is called, or when explicitly requested by
' a call to GetWindowSubclass.
Being careful to remember that we've got no instantiated objects and no dynamic arrays AFTER the stop button is pressed, it truly does seem to be IDE Stop button safe for me. I've been going in deep and then pressing it (Stop) with no ill effects. Also, executing an "End" statement results in very different results (i.e., IDE crash).
All The Best,
Apr 21st, 2017, 10:44 AM
I know I sound like a broken record, but you can replace
UnSubclassSomeWindow hWnd, AddressOf_FixedSize_Proc
UnSubclassSomeWindow hWnd, AddressOf Module1.FixedSize_Proc
Apr 21st, 2017, 12:21 PM
Ahhhh, THANK you, Dex.
I was being dense before and didn't understand. Yes, that does clean things up a bit.
Click Here to Expand Forum to Full Width
Survey posted by VBForums.