The Switchboard:A method for handling subclassing in ActiveX controls
f you develop ActiveX controls and intend to subclass or hook a window, you'll very quickly
discover a problem when you attempt to site multiple instances of your control. The subclassing,
which worked fine with a single instance of your control, now no longer works and is, in fact, most
likely is causing a GPF.
Why is this happening? The AddressOf operator requires you to place the callback routine in a
module. This module is shared between all instances of your control and the variables and subroutines
that the module provide are not unique to each instance. The easiest way to visualize the problem is
to imagine a shared phoneline (or a partyline as we hicks call it) where multiple parties are trying to
dial a number, talk, and hangup, all at the same time. What's needed is an operator, a routine that
controls the dialing (hooking), the talking (the callback routine), and who routes information to the
instance of the control that requested it.
The Switchboard subroutine (see below) and it's supporting code provides a method for subclassing
from multiple instances of your ActiveX control. It is not memory intensive, nor is it slow. It's biggest
weakness is that it is hardcoded to intercept particular messages (in this case, WM_SIZE, to trap
resize events) and will require some minor modification on your part to use.
Assumes
You will find references to myUC in the code below. Replace each instance of this with a reference
to your user control. It is very important that your code detect and respond to a subclassed window when it either closes
(WM_CLOSE) or is destroyed (WM_DESTROY). When this message is received, you should
immediately unhook the window in question. The example code provided here does this, but knowing
why it does it will hopefully save you some grief.
Code Starts
Here
Because this codes hooks into the windows messaging system, you should not use the IDE's STOP
button to terminate the execution of your code. Closing the form normally is mandatory. Debugging
will become difficult once you have subclassed a window, so I recommend adding instancing support
after the bulk of your programming work has been completed. As with any serious API
programming tasks, you should save your project before execution.
API Declarations
Public Const WM_SIZE = &H5
Public Const GWL_WNDPROC = (-4&)
Public Const GWL_USERDATA = (-21&)
Public Const WM_CLOSE = &H10
Public Const MIN_INSTANCES = 1
Public Const MAX_INSTANCES = 256
Type Instances
in_use As Boolean 'This instance is alive
ClassAddr As Long 'Pointer to self
hwnd As Long 'hWnd being hooked
PrevWndProc As Long 'Stored for unhooking
End Type
'Hooking Related Declares
Declare Function GetWindowLong& Lib "user32" Alias "GetWindowLongA" (ByVal _
hwnd As Long, ByVal nIndex As Long)
Declare Function CallWindowProc& Lib "user32" Alias "CallWindowProcA" _
(ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, _
ByVal MSG As Long, ByVal wParam As Long, ByVal lParam As Long)
Declare Function SetWindowLong& Lib "user32" Alias "SetWindowLongA" _
(ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long)
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
(pDest As Any, pSource As Any, ByVal ByteLen As Long)
Global Instances(MIN_INSTANCES To MAX_INSTANCES) As Instances