For clarity this thread is really talking about developing Custom Classes and not OOP in general. I think people fail to understand when working in Access VBA that almost every application uses extensive OOP. Anytime you are working with any object you are doing OOP. Any form, any control, recordset, collection, tabledef, etc. Everytime you use the word Set, build an event procedure, or reference a property your doing OOP. Everytime you are working with a form or report code you are doing OOP. VBA does not provide all the tenets/functionality of most object oriented languages, but if you are working with objects in VBA it is still OOP. So most vba developers are well versed in OOP by working with objects, just not versed in building their own classes.
What is good about developing and using custom classes, it gives you a better understanding of the native classes and how they work and how they can be used. A form or report class is no different in useage from a custom class. Building custom classes allows you to encapsulate a lot of functionality and hide the internal workings from the user. Although I use custom classes extensively, the most used classes I develop are like the examples posted. I take a control, form, or groups of these and basically wrap them in a class. Then you can extend the capability of these controls and groups. You can make them act as if they work together. When building custom classes the idea is to build a black box that is easily reuseable. Sometimes I will post a class to performa a function, and the response may be "you do not need to do build a class that is to complicated, you could write this code...". The comment does really make sense, because I did not write the class to solve the OPs issue. I wrote it a long time ago to solve any OP's same issue. I just imported them into an application from my library. So for example the Find as You Type combobox turns any combo box into a Find/Filter as you type. It requires one line of code to initialize. It reacts to many of the combo's events and form events, but that is transparent to the user. Yes you could write standard code to do this but each time you use it will require lots of modification of code and would be very hard to encapsulate this and make it easily reusable.
I do not know the inner workings of the native Collection class but I do know how to use a Collection to add, delete, reference, and count items. Same with working with someone elses custom classes. You just need to figure out how to use it and not how it was built.
I have seen on this thread questions of "what is the value of OOP?" Again I assume they mean "what is the value of custom classes?" because you are always doing OOP in Access VBA. Custom classes are not always the solution but can make very complex things easier and more understandable. Can make things far easier to use and more reuseable. Can wrap a lot of functionality up into a "black box" and extend the functionality of other objects.
