From Dan Mabbutt,
Your Guide to Visual Basic.
FREE Newsletter. Sign Up Now!

Feb 23 2008

In event-driven processing, a program is started, but then it just waits for some event to happen. (Actually, the CPU is executing a task that you can see in the Windows Task Manager called the "System Idle Process".)

Some examples of events are:

• A button is clicked
• A fixed period of time passes
• Data is received from another program

In Windows, these events are actually inserted into something called the Message Queue. This is really fundamental in the way your computer works. Everything that happens in your computer is placed into a series of 'messages' (actually, very much like records in a file). If you press a key, that becomes a message in the queue. So another process can simply monitor the queue and process those messages that apply to that process. The program that creates images on the screen can read the message about your key press and display the character for the key.

Early Windows programmers (usually writing in C++) had to actually write detailed code to read every event in the queue and call the appropriate event subroutine when one was found that applied to their program. (Remember, Windows is running a lot of processes at the same time. Most events, such as "the clock ticked another millisecond," in the queue won't apply.) It was technically demanding and horribly boring at the same time. That's why early Windows programs had a lot of bugs in them.

The great innovation in the first version of Visual Basic was a core system that did all this automagically. All you had to do was write the event subroutines. The Visual Basic runtime did all the drudgery of selecting the right events and calling your subroutines.

Thinking about the way things happen in "the real world" is a good way to really understand the concept. A sequential, batch oriented system is like an assembly line. If you're making cars, then steel, plastic, and other parts (the "data") are fed into the system. Workers transform these inputs into cars in a very sequential way. An event-driven system is like a department store. The store opens, but until a customer wants to buy something (the "event"), the sales staff of the store just wait. But the actual act of making the purchase is sequential again.

Although you can program your own events (and the subroutines to handle them), most events will be raised by the operating system and the Visual Basic runtime (the CLR - this was first explained in Lesson 5).

In VB.NET, most events have standard values that are passed to the code that you write. Let's look at one of the most common events that you will process, <buttonName>.Click. In this case, <buttonName> is Button1.

Private Sub Button1_Click( _
   ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
   Handles Button1.Click

When Button1 has the focus (in general, this means that the mouse is positioned over it) and the left button is clicked, the operating system passes the event to the VB.NET runtime, which passes it on to this subroutine. That's what Handles means. The same subroutine can "handle" a lot of events if that helps in your program. In "calculator" examples I have written, all ten number keys are actually buttons that are handled by one event subroutine.

In VB.NET, event subroutines always receive a sender and e parameter. But e might actually be a number of different objects. These different objects will support a wide variety of properties and methods that are different for different events. In VB 6, for example, the MouseMove event passed four parameters to the subroutine to specify the mouse position and mouse button combinations. These, and more, are available as methods and properties of a single MouseEventArgs parameter that's passed to VB.NET.)

Here's an example showing how the value of a ProgressBar component (this is similar to the colored bar that shows progress as a file is downloaded) can be changed using the X position property in the MouseEventArgs object and MouseMove:

Private Sub Form1_MouseMove( _
   ByVal sender As Object, _
   ByVal e As System.Windows.Forms.MouseEventArgs) _
   Handles Me.MouseMove
   ProgressBar1.Value = (e.X / Me.Width) * 100
End Sub

You don't have to simply accept the events that Windows and the VB.NET runtime pass to your program. You can create your own, too. To demonstrate how to do that, I recommend my article Creating Your Own Event Code.

Just as it has been for everything from OOP to event-driven programming, the real world reflects what is going on inside your computer today too. The comparison to multiprocessing and multitasking is explained on the next page.