Page 2 of 4
Step Three - The mouse events
You can group events into different categories that makes them easier to understand. Perhaps the most obvious group of events is the mouse group.
The Click and DoubleClick mouse events are obvious
||Called in response to a single click
||Called in response to a double click
Often the Click and DoubleClickevents are all you need to process but sometimes you do need to work with the mouse at a lower level.
The Mouse - Down/Up/Move events are called every time the user presses or releases any button or just moves the mouse.
||Called when any mouse button is pressed down
||Called when any mouse button is released
||Called every time the mouse moves
These three events are easy enough to understand but which object gets to handle the event?
The answer is that the object that the mouse is over handles the event but there is a subtle point. The object that handles the first MouseDown command also handles all subsequent Mouse events until the final MouseUp event. You can think of this as the object "capturing" the mouse until all of the mouse buttons are released.
These five events - Click, DoubleClick, MouseUp, MouseDown and MouseMove - allow you to define how any object behaves in response to the mouse.
The only extras are the Drag events which are designed to make dragging objects easier, but we will meet these a little later.
Step Four - Parameters
When an event occurs the appropriate event handler is called. However there has to be some way for the details of the event to be provided to the event handler. Every event handler is provided with two special objects. The first is usually called the sender and it is the object that generated the event. The second is an EventArg object which carries information about the event.
This is the first time we have encountered objects that don't correspond to controls on a form like a button but the idea is exactly the same. If it helps just think of them as invisible objects. Even though they are invisible they still have properties and methods and sometimes they even have events associated with them.
Of the two objects provided to an event handler the one that we use most often is the EventArg object - it is called EventArg because "arguments" is another name for parameters. The key idea is that the EventArg object has properties that tell you about the event. As different events need to convey different types of information there are a range of slightly different EventArg objects each with its own particular set of properties.
All of this will make more sense after an example and after you have learned a little more Visual Basic. This idea of using similar types of object with different sets of properties is a very common idea and central to the practice of object-oriented programming.
For example, if you add a MouseDown event handler, simply double click on the event in the properties window, you will see that it reads:
Private Sub Form1_MouseDown(
which on first sight does look like a lot to take in. The first line defines the event handler and the two object we discussed earlier are called sender and e (for eventargs). Let's ignore sender for the moment and concentrate on e as it is where the interesting properties are.
ByVal sender As Object,
ByVal e As
You will also notice if you read the line carefully that e is a MouseEventArgs object which is a special type of EventArgs object used to convey information about mouse events in particular.
A MouseEventArgs object has three important properties Button, X and Y. The Button property tells you which button was pressed down and X and Y give you the location where it happened.
In general you have to look up what properties an EventArgs object supports in the manual. However you can also often guess what properties are for if you start to type an instruction involving e because Visual Studio lists all of the possibilities. That is if you type e. (that e followed by a dot) then Visual Studio will list all of the properties of e and you can select one.
Step Five - Form Events
At first all of your attention is focused on the objects that you place on the Visual Basic form - but the form itself is an object and has event handlers that you need to know about. In particular one form event - Load - is vital to many programs. This event occurs when a form is loaded and before the form is visible on the screen. A few moments thought soon indicates what you can use this event for - initialisation. Anything that you need to set up before a form is used can be included in the form's Load event routine.
One particular form - the startup form - is automatically loaded when you run a Visual Basic program. Normally this defaults to Form1, i.e. the first form you create, but you can change this using the command Project,Properties and then selecting the startup form in the dialog box that appears.