Composite Controls History
(See the Access 2007 Demo Project file under the Downloads tab for an example.
The Composite Controls Object Model came about as a means of dealing with event-driven interactions with form-level controls in a way that was simple, concise, and clear to implement at the form level. It is based on a dynamic callback methodology, which allows
arbitrary methods of classes or functions of standard modules to be attached to an event, to be called when the event fires. The ability, for example, to create a custom button whose background would highlight when the mouse moved over it (a simple control
not available in MS Access), requires a significant amount of coding to manage a transparent command button control overlaid on a label control. The requisite code involved determining the label control's background state (on or off / transparent or colored)
and changing it when the cursor moved onto or off of the command button, combined with code to manage multiple buttons acting in tandem, (creating a group of "toggle" buttons or "option" buttons) can make it difficult to manage as strictly
Thus, by encapsulating this code in a series of classes which may be implemented in modular fashion, pushes this management code to the classes and leaves the form-level code to be a series of calls to instance the classes.
It is also worth noting that 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