Composite objects COM ProgID-s and Class ID-s

VaryDisp

Threading model: Apartment
Program ID: newObjects.utilctls.VaryDisp
ClassID: {0EBC57D2-59B0-4407-B42E-B886FA17DEFC}
Threading model: Both
Program ID: newObjects.utilctls.VaryDisp.both
ClassID: {AE85B219-EBC0-4e29-A766-17C6F7A12408}
Threading model: Free
Program ID: newObjects.utilctls.VaryDisp.free
ClassID: {035B1257-A684-455b-B99A-6CA95B05227E}

VaryDispCreator

Threading model: Apartment
Program ID: newObjects.utilctls.VaryDispCreator
ClassID: {835294A3-F1D0-4DFB-9C02-464178AE7416}
Threading model: Both
Program ID: newObjects.utilctls.VaryDispCreator.both
ClassID: {8BA4A092-4D55-485b-9CFF-880A9BD2196D}
Threading model: Free
Program ID: newObjects.utilctls.VaryDispCreator.free
ClassID: {76C654E9-3F98-413c-A059-8AD4634CA093}

Remarks:

The other two COM classes involved: VaryDispCtx and VaryDispImp are non-creatable. The VaryDispCtx is internally created by the VaryDispImp and access to it is provided to the scripts and other objects in the composite. The VaryDispImp class is the internal holder of the configured scripts and objects through the VaryDisp class or through definition files. Thus it is created internally whenever a composite object is instantiated and then it is controlled by its creator. In fact each time you get a composite object you get a VaryDispImp object that contains your composite object. This fact remains hidden for the both sides - the objects and the scripts in the composite and for the outer world (the application that uses the object). From outside the applications have access to the VaryDispImp's IDispatch interface which translates every call to the appropriate composite element (to the configured script or object member for the used name/DISPID).