Events are what make a program do something. In this part of our introduction to Visual Basic 2010 we take a closer look at how events are used together to create a simple drawing application.

By now you should know that all Visual Basic programs are made up of objects, their properties and the events they respond to.

In Chapter 2  we looked at properties and so logically  we need to look at events and how objects respond to them.

It has to be admitted that this is a difficult chapter for the simple reason that to produce even simple examples we have to use some ideas that aren't completely introduced at this early stage. Stick with it because it will all make sense.

Step One - The event model

A program is a list of instructions that the computer will carry out when you tell it to. Normally the machine will read and obey your instructions starting from the first and working its way towards the end of the list. In simple computer languages the order that instructions are carried out is always 100% determined by the order you write them in and this is mostly the rule in Visual Basic - but it is a little more complicated than this simple picture.

In Visual Basic you can never be sure what order your instructions will be obeyed in because they are triggered by events. Most, but not all, events are generated as the result of something the user does - click a mouse button, move the mouse, select from a menu, etc.. Windows detects the event and sends a message to the program that is active notifying them of the event. The program has the option of either doing something, i.e. responding to the event, or ignoring it.

When Visual Basic is notified of an event by Windows, it identifies which object the event concerns and then calls the appropriate event handler. An event handler is just a special sort of method that is obeyed in response to an event occurring. Each object has an event handler for every event that you can think of.

At this point programming in Visual Basic might sound impossibly complicated. You have to learn the names of all the events and write event handlers for every single one for every single object! Only of course you don't. have to!

Every object comes complete with a set of "dummy" event handlers. So by default when an event happens the appropriate object's event handler is called and, by default, nothing happens in response. In other words, you only have to worry about events that you want to worry about! In the same way while there are lots and lots of different events in practice you generally only write event handlers for a small number.

Step Two - What events?

The simplest way to see what events are relevant to an object while using the designer is to select the object - a button say - and then look at the Properties Window. At the top of the Properties Window you will see an icon that looks like a lightening flash. If you click on this you will see a list of events that the object can handle.

If you are in the code editor then you can see the events that an object supports by selecting it in the drop-down list at the top of the window.

Most users of Visual Basic find out about the Click and Double click events almost as soon as they start programming - but what about all the others that are listed. What for example, is a DragDrop event and what is a MouseDown event? The range of events that you see in the list also depends on the type of object you are working with. This means that there is always the possibility of encountering an event you have never seen before. 

If you are of a nervous disposition you can quickly decide that Visual Basic has rather a lot of detail hidden just below the surface waiting to jump out and get you! This is an accurate reflection of the situation but far from being a problem it is what makes Visual Basic easy to learn in small steps.

<ASIN:0735626693>

<ASIN:143022455X >