A premier concept in OOP programming is called encapsulation. This means is that an object has attached to it everything it needs to handle itself. We have already seen, for example, that the characteristics of an object are bound to it as properties. In addition to properties, an object can also have actions attached to it to perform specific functions. For example, if you had a light switch, you would need to have some way of toggling the light on and off when the user flips the switch. To put it in more "computerish" terms, if you had an invoice object, the procedure to print that invoice would be bound to the invoice object.
These actions which are attached to objects are known as methods.
The key here, now, is that we can attach code to any object. Going back to the light switch example, we could have a method called Toggle that turns (toggles) the light on and off. Something like this (written in pseudo-code, of course).
Procedure Toggle
IF light_is_on
Turn_Light_Off
ELSE
Turn_Light_On
ENDIF
ENDPROC
If we were to assume that we had a light switch in the kitchen (we'll call the name of the object Kitchen_Light), we could fire the method to toggle the light on and off by issuing:
Kitchen_Light.Toggle
In our customer object, we could have a method to move from one record to the next when in a form. We could call this method, Nextit, in the following manner:
Customer.Nextit
This is a very powerful way of working with code. By having a method called Nextit, which moves on to the next record, you can make your code more generic. For example, you could have a "Next" button on a toolbar that always calls a method called Nextit. The object currently being worked on (e.g., a Customer, an Invoice) could be passed through as a parameter. Thus, by executing a single line of code like:
toObject.Nextit
where toObject is the name of the parameter variable accepting the object, you could always execute the method appropriate for the current table.
Let's take the next step and look at events.