Subclassing and Hooking with Visual Basic

Creating an ActiveX Control That Subclasses Other Windows

We need to examine one last situation: creating an ActiveX control that subclasses the form that it is sited on. This gives us a way to encapsulate a subclassing routine that we can literally drop onto a form and have it work without requiring that the user of the control to do anything. The user does not even have to set any properties on the control. This is a good way to distribute common subclassing functionality between project developers without every developer having to know the intricacies of subclassing a form. For instance, if every form in an application needed to know whether a laptop’s battery was getting low on power, you could create a control that subclasses the form onto which it is dropped and then watches for the WM_POWERBROADCAST message.

Using a control to subclass the form onto which it is dropped has several problems. First, when one control is dropped onto the form, it immediately subclasses the form and stores its original window procedure. This is fine, but when a developer drops another control onto the same form, the new control subclasses the form a second time and stores what it thinks is the form’s original window procedure. Instead, it is storing the address to the subclass procedure of the first control. Actually, the application will seem to work until you close it. When you close the application, the operating system does not destroy the controls in the reverse order in which they were created; ...