Subclassing and Hooking with Visual Basic

Instance Subclassing

Subclassing a WinForm is much simpler and less error-prone than subclassing a VB 5 or 6 form module because Microsoft has written all the lower-level subclassing code for you. Now, all you really have to worry about is the code that you will write for your subclass window procedure.

To understand this better, we need to look behind the scenes at a window being created in a WinForm application. As soon as this window is created in memory, the GetWindowLongW application programming interface (API) function is called to replace the original window procedure with a new one. The original window procedure is stored so that it can be replaced when the window is destroyed. For more detail, see Section 22.7 later in this chapter.

Because the WinForm automatically takes care of subclassing and unsubclassing itself -- not to mention storing the original window procedure for later use -- we have fewer headaches to worry about when implementing subclassing. One thing that the WinForm does not automatically do, however, is write the empty subclass procedure.

Even though the WinForm handles much of the subclassing automatically, you must still follow the same rules as you did previously when writing your subclassed window procedure. For example, long complex code in the window procedure -- including displaying a message box or dialog box for user input -- will severely degrade your application’s performance. Also, you must call the original window procedure of the subclassed ...