Events are just that—things that happen automatically. For example, clicking the mouse is an event. When using objects on a Microsoft Windows® form (like a push button), you can attach code (i.e., methods) to these events. When the event happens (i.e., the user clicks the mouse on the object), the associated method is automatically called.
Events are nothing new. We have been using them the since the advent of FoxPro 2.0. Valid clauses, for example, are simply procedures which are attached to an event (attempting to exit a modified field or clicking on a push button). The power of using objects comes in attaching procedures to an object which automatically fire when something specific happens. In Visual FoxPro, for example, you can attach methods to all kinds of events: when the mouse is clicked down, when the mouse is released, etc.
There is one major difference between events in an object oriented development environment and the old valid and when clauses. In FoxPro 2.6 there was no direct method of manually firing the code snippet attached to an event (there is a way, but it is a kludge). In other words, there is no single command that says Run the procedure attached to a screen object's Valid event. In an object oriented development environment, you can do this easily by calling the event as you would a method. For example, if you had a push button called cmdOK, you could fire the Click event (which happens automatically when the user clicks the mouse on the push button) at any time by issuing:
cmdOk.Click
By attaching code to the Windows events we greatly increase the control we have over the behavior of a form.
So far, we have seen that we can create objects, assign properties to them and create methods for them. If we have to write code to fine tune an object every time we create it, we would be in for a lot of coding. Fortunately, OOP has the answer for this as well—CLASSES.