by IRBMe (22 Submissions)
Category: Windows System Services
Compatability: Visual Basic 3.0
Difficulty: Intermediate
Date Added: Wed 3rd February 2021
Rating: 
(34 Votes)
Subclassing ofers great advantages to VB programmres. This article should teach you all about the message system Windows Uses, and how to implement it into your Visual Basic Programs.
VBcoders
xmlns="http://www.w3.org/TR/REC-html40">
Windows Programming
Windows Programming
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:
Parameters: -
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:
You
would then use it like this:
"CallWindowProcA" (
uMsg
Case
clipboard has changed, so do something
messages go here
hwnd, uMsg, wParam, lParam)
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:
"user32"
TranslateMessage
Lib
"user32"
Complicated looking isn’t it? We can use these API
functions as follows:
Dim aMsg
(aMsg, 0, 0, 0)
TranslateMessage (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
WindowProc function.
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
we want
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:
Alias
"GetWindowLongA" (
Function
Alias
"SetWindowLongA" (
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
handle remember)
So, to set up a window procedure, we do this:
Private Sub Form_Load()
AddressOf
End sub
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:
Private Sub
Form_Unload(Cancel as Integer)
PrevProc
So
now we know how to:
Create
the WindowProc Function.
Set
the WindowProc function as a window procedure.
Look
for messages that we want.
Extract
values from the lParam and wParam arguments.
Process
all the other messages with the default handler.
Remove our window procedure.
Here
is a small example taken from AllApi.Net
project, add a module to it
button to Form1
Form_Unload(Cancel
Command1_Click()
are explained in our subclassing tutorial.
"user32"
ByVal dwNewLong As Long) As Long
Declare Function
CallWindowProc Lib "user32" As Long,
ByVal hwnd As Long,
ByVal Msg As Long,
ByVal wParam As Long,
ByVal lParam As Long)
As Long
Declare Function
SetClipboardViewer Lib "user32" (As Long)
WM_DRAWCLIPBOARD = &H308
(-4)
Form)
GWL_WNDPROC,
PrevProc
hwnd, uMsg, wParam, lParam)
..."
If
you want, you can create your own windows messages. However, problems can
arise. Imagine you use a message in a DLL as follows: