There's a long way to go with this thing. Nevertheless, the basic object model structure appears to be sufficient for it's intended purposes. It's important to note that the Composite Control Object Model is not intended to be implemented any more
than necessary, which harkens back to the old adage, "if it ain't broke, don't fix it." That is, if the need is met using standard, form-level event trapping code, and it's maintainable, then the Composite Control Object Model is not
With that in mind, here's a few notable deficiencies:
Right now, an error trapping object model is employed that works, but isn't implemented everywhere and really, is probably unnecessary.
Late vs. Early binding
When originally building the model, the natural inclination was to write code as generically as possible. However, this requires use of Object and Variant data types, which are late bound (weakly-typed). It would be preferable to provide more early
bound (strongly-typed) properties and methods. While there is theoretically no limit to the objects which may be used in conjunction with the Composite Controls Object Model, it will likely only consist of ActiveX objects and other Composite Controls. Further,
there's no need to be comprehensive. The object model should be minimally implemented, requiring the developer to add control types as they require for their specific project. With that said, more use of interfaces and wrapper classes that allow strongly-typed
references is possibly in order.
Further development of other Composite Controls
The object model is only as good as the uses it's been given. Without efforts to develop more Composite Controls, the weaknesses of the model cannot be easily discerned, nor can the scope be more clearly defined.
The object model uses quite a few files, largely to disperse the functions for more optimum performance under VBA. That is, the fewer functions per module, the better. Further, functions which are all likely to be used around the same time are best
grouped in one module. The result is a lot of modules, especially in the effort to move code from class modules to standard modules, thus reducing memory usage. It may be this is an unavoidable consequence of working within the limitations of VBA. Nevertheless,
thoughts on adjusting the object model to address this issue should be considered.
VBA supports Object-Oriented Programming, but really, only barely. It's a far cry from what a C++ developer can do, to be sure. Nevertheless, the basic OOP functionality that VBA provides makes this whole project possible. That said, a closer
eye on solid OOP coding practices (like maybe implementing a few design patterns) would be in order here.