Composite objects (VaryDisp objects) is a set of several classes that allow the programmer to compose single COM objects from existing objects and scripts. Composite objects are several objects and scripts bundled together exposed to the application as a single object.

In short you can get one or more COM objects write some script(s) to enhance the object's functionality and compose a composite object that exposes some methods and properties - some will be methods/properties of the COM objects used, other will be methods implemented in the script part. All these elements will be visible through a single IDispatch and will act as a single object. A similar functionality can be found in the Microsoft's Windows Script Components (WSC) but there are some considerable diferences between the composite objects and WSC:

As you can see in the table above the composite objects are targeting dynamic usage, but they also support regular COM object registration and creation techniques. At this time composite objects lack of some features as event firing support and type info but they are intended for non-visual usage and these features are rarely needed. However future versions of the DLL will introduce some of these features. Type info support makes sense only in case of registering the component in the system registry as regular COM object. The dynamic techniques - like a script that composes the object at run-time and passes it to other routines or script will not benefit from the type info because there are very few such environments where the run time COM type information will be of use. Also any change in the object should be reflected and this will have considerable impact over the performance. Therefore the first implementation of the composites is concentrated on the most important features which allow the developers to implement dynamic COM objects from scripts and existing objects.

Where and when to implement? The composite objects can be of great use if you need to pack your code in reusable form. They can be used in many environments (in fact any automation enabled environment) and packing the code in a single unit may save a lot of development time. Also using the dynamic composition/creation features one application (or part of application) is able to construct whatever is needed and pass it as regular object to another. Everybody knows the mess of the growing applications with a handy tool to pack the already stable parts of the application logic the project goes further with much less efforts and our aim is to supply a tool that allows different styles of usage. While WSC allows you to pack the logic once, the composites supply dynamic features that allow the programmer to use it in temporary form (edit the composite's script files spread on the local disks if needed) and pack it at the appropriate level when the time comes to say "it is done and works fine". In other words composite objects give more freedom on how the object will be written (For example the scripts used in the composite objects can be set as strings (e.g. the composite can be created from scripts that are even not in files). So whenever you need to serve some of the application features as an automation object the composite objects can be of great help. They combine script hosting and other COM techniques in one - there is no problem to write an object (or more than one) in VB, another in C++ and some code in script (VBScript/JScript/PerlScript) and build a composite object from them. The resulting object will look for the other parts of the application and the other applications (If the object is passed to other applications) will look as regular automation enabled COM object. The internal structure of the object remains hidden and is environment independent.

COM notes.  (COM beginners click here). 

Composite objects should be registered and created as Apartment threaded COM objects in most cases. This is a requirement if scripts are part of them. Exceptions are possible but you will need to know for sure that all the components in the composite will cope with free threaded COM apartments. We strongly recommend apartment model as default even for the skilled COM programmers.

How to use them in autorun scenarios - where the composite itself and many (or all) of the components used in it or by the scripts in the composite internally are not registered (installed). Using the internal script CreateObject/new ActiveXObject functions will not be possible because they require ProgIDs which are available only if the object is registered. Therefore you should take care to use alternatives - see VaryDispCtx.CreateObject. The CreateObject methods supplied by ActiveX Pack1 support advanced object creation techniques which will help you avoid the autorun scenario limitations.