Before the advent of Windows, many programs strictly followed a procedural design. You ran the program, and it did its work while you waited. When the program was finished, the command prompt returned and you could run another program. With Windows, a new paradigm became dominant: event-driven programming. As you interact with an application, events occur. For example, in programming terms, clicking a command button on a form or Web page raises a button's Click event. The programmer then writes a section of code to react to this event. If no such code exists, Windows simply discards the event.
You can apply the same event concepts to scripts. In other words, you can create event-driven scripts. Before I describe how to create these types of scripts, you need to know how events work and the terms used to describe that process.
An event source signals the occurrence of an event. Broadcasting this signal is called raising the event. Any object can be an event source, which is often called an event firer or event sender. An event receiver responds to an event, a process that's referred to as trapping or sinking an event. Event receivers, which are often called event handlers or event sinks, are subprocedures. So, to sum up, when an event firer raises an event, the event handler traps the event and performs an action. . . .