Printable View
What is the difference between sub-classing and hooking ?
There are several posts on these topics by legends Paul Caton and LaVolpe and other Users as well on pscode, my question is which one is stable and best one to use in projects.
Above topics are new for me and I am looking for simple and step by step technical information or tutorial to understand these topics. Any link to such topics will be appreciated. :)
See:Quote:
Originally Posted by webloper
It depends on what you're trying to do. Please refer to the links above to understand when to use one over the other.Quote:
Originally Posted by webloper
Check out these tutorials in the CodeBank:Quote:
Originally Posted by webloper
Thanks for the links.:thumb:
Let me rephrase my question, by Paul there are 6 posts on same topic; one by LaVolpe and one by Vlad.Quote:
It depends on what you're trying to do. Please refer to the links above to understand when to use one over the other.
As we know PSCode creator, added all the posts again after they lost the data. Due to this reason it is difficult to understand which code is last and updated one. I think WinSubHook2 Thunks - updated 2/13 is the last and updated, not sure though.
LaVolpe combined all the codes and created a single file. SelfSub, SelfHook, SelfCallback by Paul Caton :thumb:
I like Paul's WinSubHook2 Thunks - updated 2/13 as it is modular, but not sure it is stable and updated.
That's why I like to know which one is stable and better one as most of them are doing same work. :(
Ah, sorry I misunderstood. :oQuote:
Originally Posted by webloper
I don't really have any experience with any of those subclassing thunks so I'm afraid I can't give you sound advice on which one is the best. I happen to prefer to keep my subclassing code lean and mean and I've also learned to be careful when debugging subclassed code, so I've never felt the need for such subclassing helpers.
If full debugging support is needed, you can use my subclassing dll.
It uses the common controls subclassing API currently preferred by Lavolpe (and the community generally).
No need for thunks / assembly.
Truth be told, I often confound the usage of Subclass and Hook (and LaVolpe has corrected me on more than one occasion). :)
But, it's my understanding that subclassing is reserved for windows (by "subclassing" some hWnd). And hooking is reserved for things such as the keyboard, mouse, or possibly other hardware devices (using their handles). I've never really seen that much difference. In both cases, we're inserting our own procedure in a chain-of-procedures so that we can modify/enhance/superclass the way something is working.
I will admit though, as of late, I've been trying to say things like "subclassing procedure" rather than "hooking procedure" when referencing a procedure used for subclassing.
Now UserControl (UC) seems to be in an entirely different category. I suppose, in a certain sense, we could say that we're "subclassing" intrinsic VB6 controls to make a "super-control", but that's a bit of a bastardization of the terms (in terms of the way they were intended).
I will also admit that it took me a while to come to terms with the true meaning of "subclassing". It's really nothing more than taking some hWnd of a window, and inserting our own procedure (function) at the end of the call-chain. In my mind, that window (and its associated hWnd) had a certain level of functionality. But, by adding new code to the call-chain, we've "subclassed" it's core functionality and added new capabilities (thereby creating a super-class).
Take Care,
Elroy
Elroy,
Subclassing is not equal to superclassing.
[...]
Edit: but it's similar. ;-) not necessary to fiddle further with the definition.
Yes, I prefer not to use thunks now that common controls offered their subclassing via APIs. Even with Paul's code, if a window is subclassed more than once (think of multiple instances of a usercontrol that subclasses its parent), unsubclassing in the wrong order can cause crashes. In one of my attempts to remedy that, I tried to use a linked list approach on Paul's thunks, to get past that problem. Long story short -- thunks were great when Paul first introduced his. But since then, the common controls approach (or external DLL approach) are really stable and far easier to use/update as needed.Quote:
Originally Posted by DEXWERX
I've not given up on thunks and believe they have their purpose in some scenarios. For example, a project I'm working on uses thunks to subclass some COM interfaces and is IDE crash proof -- I've tried hard to crash but can't. Another scenario, though a weak argument, is to use thunks to prevent the need for a bas module.
I want to avoid thunks wherever possible.
My reason: On some VM's there just don't work for security reasons. (In business environments)
Hmm, there are so many new terms for me now :bigyello: "common controls subclassing API" and thunks; Googling now... :thumb:Quote:
Originally Posted by DEXWERX
I checked your VBSubclassing code and Min-Max example, it's not open source :( so I don't understand what's going under the radar. Still its in my code stack, Thanks! :thumb:
As per my understanding there are different terms used according to the context, for me subclassing is adding something new to parent class like as OOPS concept ( logically ;) ) not sure though.
Under the hood it's using the same API nicely detailed by LaVolpe and already posted above. http://www.vbforums.com/showthread.p...ntrols-LibraryQuote:
Originally Posted by webloper
The necessary puzzle pieces for IDE safety have been worked out by Lavolpe/Wqweto/Caton/Peterson.
Eduardo and Wqweto have similar DLLs in production use.
Yes, Thanks! Going through all the details.Quote:
Originally Posted by DEXWERX
You might also be interested in this subclassing & hooking example.
I think this gives a pretty good definition on how to differentiate the two:
Quote:
Subclassing lets you watch for messages sent to any object. In this case it was the form. It could have been a textbox, toolbar, etc. Although the two are very similar, do not confuse subclassing with using hooks. Briefly, a hook allows you to see all messages sent to an entire thread, regardless of the active window. When using hooks, you do not replace the window procedure with your own. Instead, you add your procedure to the top of a chain of procedures. Each hook procedure is responsible for calling the next procedure in the chain. Failure to do so does not cancel the message but merely prevents the other procedures in the chain from seeing the message.
Source: http://www.thescarms.com/VBasic/subclassform.aspx
That statement is a bit confusing to me. You don't really "replace" the procedure with our own in either case. However, in both cases (hooks or subclassing) we certainly can prevent further downstream procedures from "seeing" the message. However, in neither case, can we stop upstream procedures from "seeing" the message. There are possibly other approaches (beyond the purview of hooks and subclassing, i.e., replacing VTable addresses) where we could "replace" procedures, but that's not quite what's being asked.Quote:
When using hooks, you do not replace the window procedure with your own. Instead, you add your procedure to the top of a chain of procedures. Each hook procedure is responsible for calling the next procedure in the chain. Failure to do so does not cancel the message but merely prevents the other procedures in the chain from seeing the message.
Take Care,
Elroy
That's closer to the truth.Quote:
Originally Posted by webloper
People often assume subclassing means something else because they often use WNDPROC hooking on controls to alter, replace, or enhance the actions performed in response to various window messages. However it can also be done by sending messages to the control.
Often this is desired because they are using a control class that itself subclasses some superclass. When that subclass hides a feature or behavior they may want to subclass the subclass to reach the superclass and reimplement a feature hidden by the superclass. Or maybe the control subcalss just doesn't implement some feature that has been added to the underlying superclass since the subclass was written and compiled.
Consider the following:
Attachment 156653
There I used two forms of "subclassing." One extends the VB.TextBox by adding the ability to set left/right margins and tab stops. The other extends the Strings.Format$() function by going directly to oleaut32.dll to use its functions to gain the ability to specify a desired LCID.
No hooking used at all.
Some might argue that the second case is not subclassing. I won't disagree with that, but it is pretty darned close to what most subclassing is used to accomplish.
Others may try to say the first case is not subclassing. I would strongly disagree with that.