Guy Eddon
Henry Eddon

Guy and Henry Eddon have written articles on Visual Basic, Java, and COM, which have appeared in Microsoft Systems Journal and Microsoft Interactive Developer. They are the authors of Active Visual Basic 5.0, published by Microsoft Press.

Introduction

You've probably heard of the Microsoft? IntelliMouse? pointing device with the rotating wheel control that also serves as a middle mouse button. The wheel is normally used by applications as a hardware alternative to scroll bars. Wouldn't it be neat to add support for the wheel to your Microsoft Visual Basic?–based applications?

You can use Microsoft Visual Basic to build an ActiveX? control that enables your applications to support all the features of the new mouse. This feat does require you to use advanced Visual Basic techniques and the Microsoft Win32? application programming interface (API), but amazingly, you don't need to write any C/C++ code.

The features of the IntelliMouse have native support in Microsoft Windows NT? version 4.0, but they require special drivers (included with mouse) to work with the Microsoft Windows? 95 operating system or earlier versions of the Windows NT operating system.

The sample code shown here supports IntelliMouse features for Windows 95 and Windows NT version 3.51 only. A more complete version of this ActiveX control, one that adds support for Windows NT 4.0, can be found in the book Active Visual Basic 5.0, published by Microsoft Press? (http://mspress.microsoft.com/).

How It's Done

Whenever the user operates the wheel control of the IntelliMouse, a special message known as MSH_MOUSEWHEEL is sent. The Win32 API call RegisterWindowMessage obtains the unique identification number of the MSH_MOUSEWHEEL message:

rotate_msg = RegisterWindowMessage(MSH_MOUSEWHEEL)

To trap this message from a Visual Basic–based program, you need to install a Windows message hook in your program. You do this with the SetWindowsHookEx Win32 API call:

hHook = SetWindowsHookEx(WH_GETMESSAGE, _AddressOf GetMsgProc, 0, GetCurrentThreadId)

SetWindowsHookEx requires the address of a "callback function," a function that is called automatically by Windows each time a message is sent to the application.

The AddressOf operator is used to provide the pointer to a callback function residing in a code module:

Public Function GetMsgProc(ByVal nCode As Long, ByVal wParam As Long, lParam As MSG) As Long
   If lParam.message = rotate_msg Then
       MyControl.WheelMoved lParam.wParam, 0, lParam.pt.X, lParam.pt.Y
   End If
   GetMsgProc = CallNextHookEx(hHook, nCode, wParam, lParam)
   End Function

The CallNextHookEx Win32 API call chains the message hook. Because some other control might have installed a message hook before our control did, it is polite to still allow that control to receive messages after we finish examining them.

GetMsgProc = CallNextHookEx(hHook, nCode, wParam, lParam)

The callback function's main purpose is to check each incoming message to determine if it originates from the wheel control.

If it does, we want to notify the application using the control that the mouse wheel is being manipulated. The best way to do this is to fire an event in the control.

The control defines a WheelRotate event fired whenever the mouse wheel is rotated. The Delta value indicates the degree to which the mouse wheel has been rotated. This value will be some multiple of positive or negative 120.

A positive value indicates that the wheel is being rotated toward the screen, and a negative value indicates rotation toward the user.

Event WheelRotate(Delta As Long, Shift As Long, X As Long, Y As Long)

Events can be fired only from within a UserControl module, while the callback function must be implemented in a code module. For this reason, whenever an MSH_MOUSEWHEEL message is intercepted, we call a Friend function in the UserControl module whose sole purpose is to fire the event:

Friend Sub WheelMoved(Delta As Long, Shift As Long, X As Long, Y As Long)
    RaiseEvent WheelRotate(Delta, Shift, X, Y)
End Sub

Before the control is terminated, the Windows message hook should be uninstalled. The Win32 API call UnhookWindowsHookEx does the trick:

UnhookWindowsHookEx hHook