Part 1 – Messages
How does the Window Operating System know what you are
doing? How does it know when you click, where you click and with what button
you click? How does it know when you press a key, what key you pressed and what
window you are typing in? There are
many questions with only one simple answer. The answer being a message system.
There are many hundreds of common Windows messages, which
include the left mouse click, the right mouse click and also the key down, and
key up messages. There are other messages other than those used to indicate
user input. There is also a message for instance that tells a window to repaint
(or redraw) itself and also a timer message.
So how do applications receive these messages? The answer is
a “window procedure”, although not official, it is generally agreed that it
should be called “WindowProc”. The window procedure is a function that will be
called every time a message is sent to that window. It must be declared as a
public function in a module! It looks like this:
Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, _
ByVal wParam As Long, ByVal lParam As Long) As Long
hwnd – The window
handle of your window. A window handle is a unique number, which is assigned to
your window. Whenever you call an API function that wants to do something with
your window, you must pass the hwnd property
uMsg – This is the number of the message that was sent your
window. For example:
Public Const WM_DRAWCLIPBOARD = &H308
‘Declare this message as a const, making it easier to deal with.
would then use it like this:
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) As Long
‘The data in the
clipboard has changed, so do something
‘Case ... Other
messages go here
WindowProc = CallWindowProc(PrevProc,
hwnd, uMsg, wParam, lParam) ‘Process all
those other messages that we don’t care about
wParam/lParam – These are general parameters and can store pretty
much any values including other sub-messages. If memory serves me correctly
then the mouse move message comes with the X and Y coordinates of the mouse
stored in the wParam and lParam parameters.
Now some of you may be thinking, “I hope I don’t have to
process all of the hundreds of messages, my code could be thousands of lines
long”. For those of you who weren’t, well you are now. The answer is thankfully
no. There is a default window procedure that will carry out the basic commands
like painting your window, resizing it, moving it, giving it focus, and all of
the hundreds of other things.
We have a lot of control when it comes to messages. We can
create our own messages, send messages to the system and look at all the
messages in the message queue. Consider the following API functions:
Declare Function GetMessage Lib
"user32" Alias "GetMessageA" (lpMsg As Msg, ByVal hWnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax As Long) As Long
TranslateMessage Lib "user32" (lpMsg As Msg) As Long
Declare Function DispatchMessage
"user32" Alias "DispatchMessageA" (lpMsg As Msg) As Long
x As Long
y As Long
hWnd As Long
message As Long
wParam As Long
lParam As Long
time As Long
pt As POINTAPI
Complicated looking isn’t it? We can use these API
functions as follows:
Dim aMsg as Msg
(aMsg, 0, 0, 0)
Call DispatchMessage (aMsg)
I think that is pretty self-explanatory.
VB has a built in message handler in its form object. This
is where the events come from on your forms, and also the controls as well.
These events are just generated whenever the corresponding messages are detected
in the window Procedure. And the X and Y values in the MouseDown event for
example are just extracted from the lParam and wParam arguments in the
Now, why would you want to write our own message handler if
VB already provides a perfectly good one?
VB hides a lot of the Messages from us
VB deals with some messages in a way that might not suit what
VB processes its messages before sending us the event. What if
we don’t want it to do anything?
Let us consider the rather complicated topic of Winsock API.
The way Winsock lets us know what is going on is through messages sent to our
window’s message handler. However VB hides these ones from us. In order to see
them, we will have to create a window procedure of our own.
Now, how do we tell windows to send messages to our new
window procedure? Like so:
Private Declare Function GetWindowLong Lib _
"GetWindowLongA" (ByVal hWnd _
As Long, ByVal nIndex As Long) As Long
Function SetWindowLong Lib _
"SetWindowLongA" (ByVal hWnd _
As Long, ByVal nIndex As Long, ByVal dwNewLong _
As Long) As Long
Those are 2 new API calls, one creates a window procedure,
and the other returns the address of a window procedure given the hwnd (window
So, to set up a window procedure, we do this:
Public Const GWL_WNDPROC = -4
Private Sub Form_Load() ‘Of course it doesn’t have to go in form load
PrevProc = SetWindowLong(hwnd, GWL_WNDPROC,
You can replace the “AddressOf WindowProc” with the name you
have given to your window procedure, but I suggest you keep the name to
WindowProc. Also remember WindowProc must be a public Function, written with
the correct parameters and everything, in a public Module.
This API call returns the handle to the previous window
procedure if one exists
We must store a value into PrevProc so that we can return
the default Window Procedure when we are finished. So, how do we return the
previous window procedure? Like this:
Form_Unload(Cancel as Integer) ‘Again, doesn’t have to be in Form_Unload
If PrevProc <> 0 Then
SetWindowLong hwnd, GWL_WNDPROC,
PrevProc = 0
now we know how to:
the WindowProc Function.
the WindowProc function as a window procedure.
for messages that we want.
values from the lParam and wParam arguments.
all the other messages with the default handler.
Remove our window procedure.
is a small example taken from AllApi.Net
'Create a new
project, add a module to it
'Add a command
button to Form1
'In the form
Private Sub Form_Load()
'Subclass this form
'Register this form as a Clipboardviewer
Form_Unload(Cancel As Integer)
'Unhook the form
'Change the clipboard
Clipboard.SetText "Hello !"
'In a module
are explained in our subclassing tutorial.
Declare Function SetWindowLong Lib
"user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long,
ByVal dwNewLong As Long) As Long
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)
SetClipboardViewer Lib "user32" (ByVal hwnd As Long) As Long
WM_DRAWCLIPBOARD = &H308
Public Const GWL_WNDPROC =
Dim PrevProc As Long
Public Sub HookForm(F As
PrevProc = SetWindowLong(F.hwnd,
GWL_WNDPROC, AddressOf WindowProc)
Public Sub UnHookForm(F As Form)
SetWindowLong F.hwnd, GWL_WNDPROC,
Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
WindowProc = CallWindowProc(PrevProc,
hwnd, uMsg, wParam, lParam)
If uMsg = WM_DRAWCLIPBOARD Then
MsgBox "Clipboard changed
you want, you can create your own windows messages. However, problems can
arise. Imagine you use a message in a DLL as follows:
Const MYMSG = WM_USER + 7
lets then imagine that another DLL uses the exact same message for something
completely different. Now to make matters worse, some poor person tries to use
the two DLL’s in the same project. Let the errors and bugs and problems
commence. Well, there is a way around this:
Declare Function RegisterWindowMessage Lib "user32" Alias
lpString As String) As
this will do is allow you to create unique message numbers. Lets say you wanted
to create your own message, you would do something like this:
= RegisterWindowMessage (“MyUniqueString”)
will assign MY_MESSAGE a new unique message number every time it is run.
However, if you put this in a DLL then how will the applications using the DLL
know what the number of your message is? They do EXACTLY the same thing as
above. When they enter “MyUniqueString” into the lpString Parameter, because it
already exists (it was originally made by your DLL remember), it will now
return the number that it assigned to MY_MESSAGE. Consider the following
= RegisterWindowMessage (“MyFirstString”)
“Your first new message is “ & MESSAGE_ONE
= RegisterWindowMessage (“MySecondString”)
“Your second new message is “ & MESSAGE_TWO
“How do we retrieve message one? Like this: “ & RegisterWindowMessage (“MyFirstString”)
“How do we retrieve message two? Like this: “ & RegisterWindowMessage (“MySecondString”)
that’s the end of this tutorial. Let me just tell you that the technical name
for this is called Sub classing, in case you ever hear it referred to as that.
hope that after reading this you understand everything, however if there is
anything you still don’t understand then visit http://www.AllAPI.net
and search for one of the API declarations mentioned in the tutorials.
Alternately, search for WindowProc, or Subclass. They should get you something.
just like to say how long it took me to highlight all that code in its correct
colouring, so if anybody has a good program to do that automatically, I’d be
I know there are loads of people out there who know the ins and outs of Windows
messaging, and have read this for whatever reason. I know I read tutorials on
things I know inside out anyway. So, for any of you experts who have read this,
any concerns with the tutorial (Misinformation, bugs in code, even typo’s),
then I’d like to know, so leave a comment if you want.
also like to know if I have helped people, and if so, how much. So some
comments there wouldn’t go amiss.