This project is read-only.

Project Needs

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 necessary.

With that in mind, here's a few notable deficiencies:

Error trapping

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.

Module-heavy architecture

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.

Last edited Dec 31, 2010 at 3:37 AM by vba_junkie, version 2


No comments yet.