Chapter 8. Delegates and Events

Because Visual Basic is built on the foundation of the .NET Framework, it is object-oriented. But because it is designed for use in the Microsoft Windows environment, it is also event-driven . In standard procedural languages, all statements encountered in the program are processed from beginning to end. The program begins at the start of the main routine (or its equivalent) and continues to the end, sometimes taking detours into other routines, but always as dictated by the organization of main.

In event-driven programs, a procedure can be called that has no direct or indirect relation to the main routine. In fact, very little code within a typical event-driven application is called from main or any of its descendants. Most code is called by events, user- and system-initiated actions that seek some outlet in your application's code. Events are the natural programming style of any system with multiple user input possibilities (keyboard, mouse, touch screen, the user pressing the system's power button, etc.).

Perhaps you have a program that simulates a cat. Of course you will include a Meow procedure that emits the language of the cat.

     Public Sub Meow(  ) 

Your cat program will need to respond to external stimuli, just like a real cat. This requires events. One such event might be the SteppedOnTail event that, when triggered, calls the Meow method. Other events, such as SeeDog and CraveMilk, might also call the Meow method.

In .NET, any class can respond to a set of events specifically designed for use in that class (or a family of inherited classes). When events are triggered, they call special event-handling routines through a system of delegates. Although you will usually implement a single event handler (defined below) for each event of interest, events and event handlers can also exist in many-to-many relationships. One event, when triggered, can call multiple event handlers, and a single event handler can be used for multiple events.