Microsoft KB Archive/327866

= INFO: Subclassing Support in Visual Basic =

Article ID: 327866

Article Last Modified on 8/11/2006

-

APPLIES TO


 * Microsoft Visual Basic 5.0 Enterprise Edition
 * Microsoft Visual Basic 6.0 Enterprise Edition
 * Microsoft Visual Basic 5.0 Professional Edition
 * Microsoft Visual Basic 6.0 Professional Edition

-



This article was previously published under Q327866



SUMMARY
Subclassing intercepts messages that the operating system sends to specific windows. Subclassing allows you to process messages that are not handled natively by a control or form.

Subclassing requires that you use the AddressOf operator, which provides callback functionality. For more information about how to use this operator, visit the following MSDN Web site:

AddressOf Operator

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vaopraddressof.asp

NOTE: The AddressOf operator provides callback functionality when it calls Windows APIs that require this feature. This functionality is also known as a function pointer. The AddressOf operator was not designed or tested for subclassing purposes. Subclassing can have disastrous results if you use it incorrectly.

Microsoft supports the demonstration of subclassing in Visual Basic. Some controls may experience problems if they are made into a subclass, because their intended behavior is modified beyond the original design. Therefore, subclassing in Visual Basic does not always work. Microsoft does not guarantee that subclassing in Visual Basic will produce the results that you want.



MORE INFORMATION
The limitations and risks of function pointers in Visual Basic include the following:

Debugging: If your application fires a callback function while it is in break mode, the code is executed, but any breaks or steps are ignored. If the callback function generates an exception, you can catch it, and then return the current value. Resets are prohibited in break mode when a callback function is on the stack.

Thunks: Windows enables relocatable code by using thunking. If you delete a callback function in break mode, the thunk is modified to return a zero value. This value is typically correct, but not always. If you delete a callback function in break mode, and then you type the callback function again, it is possible that some call recipients will not know about the new address.

Thunks are not used in the compiled executable. The pointer is passed directly to the entry point.

Passing a function with the wrong signature: If you pass a callback function that takes a different number of arguments than the caller expects, or if you pass a callback function that mistakenly calls an argument by using ByRef or ByVal, your application may fail. You must pass a function with the correct signature.

Passing a function to a Windows procedure that no longer exists: When you make a window into a subclass, you pass a function pointer to Windows as the Windows procedure (WindowProc). However, when you run your application in the IDE, the WindowProc function may be called after the underlying function is destroyed. This may cause a general protection fault, and may cause the Visual Basic development environment to fail.

Visual Basic to Visual Basic function pointers are not supported: Pointers to Visual Basic functions cannot be passed in Visual Basic. Only pointers from Visual Basic to a DLL function are supported.

Containing errors in a callback procedure: Any errors in a callback procedure must not be propagated back to the external procedure that initially called. Therefore, put the On Error Resume Next statement at the beginning of the callback procedure.

