CodePlexProject Hosting for Open Source Software
A Composite Control is not a control in it's own right. Rather, it is an encapsulation of code that manages an existing control or the interactions between several controls. There's no limit to the number of existing controls that may comprise
a "Composite Control", nor is the functionality limited to making flashy user interface effects. Further, any VBA object, whether it's a control or a custom class that manages controls, may be managed by a Composite Control. Composite Controls
are typically event-driven with the ability to sink and source standard or custom events.
It's important to note that the Composite Controls Object Model isn't intended to replace the default method of trapping control events in VBA. That is, if your needs are met by simply using form-level code, then you've no reason to
use this object model. In fact, if you don't generally have issues writing your user interface event code, you'll probably have no need of it, either. However, if you often find yourself trying to develop unique control interactions that aren't
native to the ActiveX controls at your disposal, or wish a particular control had some extra functionality (like an Access.TabControl with a RecordSource property), then the Composite Controls Object Model may prove useful.
One of the drawbacks to VBA object-oriented programming is that a class requires a separate file. In addition, VBA doesn't support inheritance, a key concept to OOP. These two constraints create more files than should be necessary. Further,
because VBA loads modules on an "as needed" basis, it makes sense from a performance standpoint to off load class-level functions into a separate module to reduce memory demands (a support module is loaded only once, though hundreds of copies of
the class module may be created), and to separate functions into separate modules according to the point in the application they get used.
The purpose of the project is to develop the object model to make it easier for VBA users to write their own Composite Controls to suit their needs. That said, it's the development of composite controls that tests the model and it's stability.
So the answer, I guess, is "it depends".
The best answer is "it depends". In order to provide the most reusable code, late-bound referencing is used (Variant and Object data types) in many cases. There's also the Object Model hierarchy to consider. Implementing classes means
making function calls which adds overhead. For that reason, the object model structure is intentionally shallow. Further, the most useful aspect of the Object Model employs the notoriously slow CallByName() function. Despite the overhead, prolific use of this
function does not appear to greatly impact the overall performance. That is, since the object model is event-driven and most events are fired in response to action at the user interface level, the events don't occur frequently enough to cause problems.
Even when trapping the frequently-firing MouseMove event (cControl_WebButton) did not result in noticeably slow performance. In the end, the most noticeable latency is on startup, when the Form containing the Composite Control classes opens.
Last edited Jan 18, 2011 at 5:33 PM by vba_junkie, version 4
Ads by Developer Media
| Ad revenue is donated.
Sign in to join this project.