Classes in Access

For some curious reason, creating objects in Microsoft Access has lately become a popular topic, in various newsgroups devoted to Microsoft Access. As one who has invested  I feel compelled to contribute something on this topic.

1. In the purest sense, Access is NOT an Object-Oriented Language, and not quite an Object-Based Language. It falls somewhere in between. You can create classes, and declare both methods and properties of said classes. However, you cannot do some things that are crucial to a true O-O language, including inheritance and polymorphism. Nor can you create abstract classes.
2. That said, there remain lots of very useful things an Access developer can do. In subsequent comments to this thread, I shall post a few examples, and post links to various Access files.
Before we get to that, however, let's review some of the advantages to classes.
a) Reusability: In a subsequent blog, I'll show you how to create a custom form control that behaves like a textbox but is more intelligent. When it acquires the focus, it changes colour, and when it loses the focus, it restores the original colour. You could code that behaviour by hand of course, using the GotFocus and LostFocus events, but you'd have to do that for every textbox control on a form. By creating a custom class that implements this behaviour, you only have to do it once, and then declare all your textboxes as instances of this custom class.
b) Encapsulation: Think of this as code-hiding. Staying with the current example, all the code that implements this custom behaviour is hidden from view, unless and until you want to examine it in detail. For example, suppose you discover a bug in the implementation. You fix it once and all your instances are automatically corrected. Perhaps more important, your form's code is not cluttered with repeated instances of this code.