VB6 and VBA are very primitive when it comes to working with classes. With your background have you considered building this in Visual Studio? Although I consider myself a expert in Access VBA, I have been developing in VB.net for the last year. I am just so impressed. The design environment makes everything so easy and the VB.net is so robust. I am just using VS express with SQL express all for free, and you can do some pretty impressive things. Now coding in vba is becoming painful. It seems in a lot of your questions, you are trying to figure out ways to do things that cannot be done in vba, but are easily done in vb.net.
Below you say:
Bit disappointed at the amount of fairly simple tasks needing to call the API.
Are you referring to VBA or .net.
Read this article. For working with classes in vb6 and vba. This will show you the accessors using get, let, and set procedures.
Here is one reason to make class variables private with public accessors, but there many others:
should I still be able to access the nested members?
Again, I hate to be picky but the term is not nested. In OOP the term is "Containment" or "Aggregation". Containment means that an object contains another object. This is a "Has a" relationship. This is different from inheritence where you have "is a" relationship. A "dog" class should inherit from an animal class because a dog "is an" animal. A customer class should contain an adress class because a customer "has an " address. Nested classes are a "has a" relationship with the stipulation that it really only exists in the context of the parent class. Unfortunately VBA does not support inheritence or nesting.
should I still be able to access the class properties?
Yes of course. That is the whole purpose. See the link above. You do this almost every time you write vba code.
Forms.item("frmName").controls.item("controlName").value = 2
The control object has value property with a getter and setter
The controls collection has an item property with a getter and setter. (Note. Most times you omit the item property because it is the default property)
I have seen an example of an interface, essentially a class with no procedures, Is that actually what it is or is it differently named and only mimicing an interface
Unfortunately yes.
Versions of Visual Basic prior to Visual Basic .NET could consume interfaces but not create them directly. Visual Basic .NET introduces the Interface statement, which allows you to define true interfaces as distinct entities from classes, and to implement them with an improved version of the Implements keyword.
I never found a real use for interfaces in VBA. In vba it is nothing more than a contracts that says if you implement this class then you have to provide the same methods. In VB.NET and other languages interfaces introduce another level of abstraction that you can apply to your program logic. By declaratively implementing an Interface in many Classes, you can then refer to instances of those Classes
through the Interface type. Then, you can call the Interface functions, which will invoke the specialized functions from the Classes. This makes it possible to streamline the logic in your program through data-directed design. That cannot be done in vba.