isual FoxPro developers have been using an event-based methodology for a very long time, but event handling in VFP 8 opens a new world to developers who need to "hook" various events to custom code. With the new BINDEVENT() function, Microsoft has handed over a fabulous new capability to those who dare to use it. But don't worry! Things are still just as easy and painless as they were in previous versions. But Visual FoxPro 8 adds a whole lot of flexibility to the event mechanism. Before we delve into the details of the new functionality, let's examine what we had in the previous version.
For Visual FoxPro developers, an event and the code that reacts to it are one and the same thing. But that's actually incorrect. An event is a very different animal from the code that runs when an event occurs. Let's look at a simple example.
Let's assume we drop a button on a form. The button is a Visual FoxPro standard control (base class) that comes with a whole lot of functionality that is exposed to the developer as properties, methods, and events. This is known as the button's "interface." By that we mean programming interface, and not the user interface.
One of the most frequently used features of a button is the Click event. When we double-click this event in design mode in the property window, Visual FoxPro opens the code window, showing the Click() method. For this reason, most developers think that the Click() method and the Click event are one and the same thing. That's not the case.
|What is interesting here is that we can have more than one handler for an event. In fact, we can add as many different event handlers to each event as we want!|
When we add code to the Click()
method, we are not really touching the button's event at all. Instead, we simply put code into a method that goes with the button's instance. When we compile the whole thing, Visual FoxPro realizes that the code we wrote is meant to go with the button object. Visual FoxPro can also look at the button's interface to see that the button might occasionally raise a Click
event. Therefore, VFP compiles our code and links it to the button by simply using a naming convention that says the whenever there is a method with the same name as an event, that method is executed when the event occurs.
Note that this fact is specific to Visual FoxPro. If the designers of VFP had decided that the name of a click method would be prefixed by "On," then the method that goes with the Click event would have to be called "OnClick". (This, in fact, is a convention used by other development environments). So the name itself isn't really important. What's important is that there is some naming convention that allows the compiler to automatically link our code to the event. Otherwise, we'd have to establish the link manually, which would be a lot of work.
But sometimes, this may be desired! Perhaps we would like to dynamically attach and detach event handling code. Or perhaps we would like to handle different events with the same event handler. And that's where VFP8's new event binding comes in!