Subclassing is a technique that programmer’s can use to intercept Windows messages. This works by replacing VB’s default Window Procedure with your own, custom Window Procedure.
Every time the user does something, say, move the mouse, Windows sends a message to your form. Visual Basic normally handles and processes these messages and for some of them it creates events for. If you look at your form, the Click event is created and activated by Visual Basic when it receives a message from Windows telling it that the user has clicked on the form.
The problem is, Visual Basic doesn’t create events for all of these messages, so we are left without ways of detecting certain things. For example, when the user resizes a form, VB creates an event Form_Resize. But this event only fires after the user has finished resizing the form.
Using subclassing, you can intercept this reisze message, and, before the user has finished resizing, you can apply your own restrictions. This principle can be applied to many messages.
Subclassing as we now know it was made possible by the AddressOf keyword brought in with Visual Basic 5. Before that developers had to use a third party control if they wanted to carry out subclassing.
The AddressOf keyword, which is only used several times in a complete subclassing routine, returns the address of a procedure. This may sound useless, but we can use it to get the address of our own Window Procedure.
Once we have the address of our Window Procedure, we can use the SetWindowLong API call to set our Window Procedure in place of VB’s own one.
Now we have redirected the messages, all we need to do now is process them. A simple Window Procedure has the following arguements:
hWnd – The Window Handle (Long data type) usually the form you are going to subclass.
uMsg – The message sent by Windows.
wParam – Additional information about the message.
lParam – Additional information about the message.
Inside the Window Procedure, we use the Select Case statement to check which message is being send. The different Cases will be the messages that we want to process. In theory, you could place every message here, but it would be slow to process and might cause the system to fail. So instead we just place our own messages and pass the rest onto VB’s own Window Procedure.
When you come to closing down your application, be sure to pass control back to VB. Earlier in the proceedings, your code should store the value of your Window Procedure. If you don’t restore full control back to VB, your program, and quite possibly Windows is likely to crash. Many people choose Windows NT for their development OS as it is more stable, and only VB (IDE) or your application will go down, and not Windows.
Anyway, check out the controls at the top and keep an eye on this section as we will be adding more information soon. A site that I reccommend you see is Steve McMahon’s vbaccelerator.com. Provided you can digest the complicated stuff, you should be alright. His site contains numerous examples of subclassing and he has his own Subclassing DLL.
If you have any comments on this article/section or want to contribute then please email the webmaster at: sam@vbsquare.com
