Introduction to the Composite Controls Object Model
The Composite Controls Object Model was designed with the idea of encapsulating complex, event-driven interactions between ActiveX controls in VBA projects. At present, it has been developed entirely in Microsoft Access 2007.
Why an "Object Model"?
Initially, the project began as a way to create "web buttons" - transparent command buttons overlaying a label which changes background color when the mouse moves over the command button. But as the project developed, the hierarchy proved useful in
managing most any type of event-driven interaction between ActiveX controls, forms, or any other event-sourcing VBA object. Thus, the project has adopted a more generic focus, to provide a development framework for creating a "composite control"
or a custom class which manages event-driven interactions between ActiveX controls, forms, recordsets, other composite controls, or anything that may source trappable events within VBA.
This, then, shifts the focus from building widgets to building an object model for building widgets. The end result is a structure that may be useful for a variety of applications, like creating visual effects for standard controls, binding controls / forms
to one another or perhaps creating a complex control like a filmstrip-style image gallery or javascipt-style menu system.
VBA Code, No More, No Less
The object model was initially developed in a rather macro-unfriendly environment. Many VBA projects run under tight macro rules which do not permit users to install third-party software or use more advanced VBA functionality (like access to the VBA project
object model). While some IT environments are more restrictive still, a driving concept behind the Composite Controls Object Model was to provide the sort of advanced functionality that a 3rd-party application can provide, without requiring anything more than
simple permission to run VBA macros attached to Office documents. No additional project references, no third-party controls, no low-level VBA project manipulation required (or allowed).
While this requirement certainly restricts what the object model ultimately can and cannot do, it does ensure that it should function without difficulty in all but the most restrictive macro environments.
You can view blog posts related to the history of the Composite Controls Object model on the Microsoft Access Team Blog:
Using Dynamic Event Callbacks
Power Tip: Experiment with dynamic event callbacks
If you like, you can also
download the original demos from these posts here