ActiveX Controls used in core Office Applications (such as Word, Excel, PowerPoint, or Visio) are bound using ITypeInfo from an associated type library (*.tlb) and extender library (*.exd) when created or loaded inside a document or macro dialog form (VBA UserForm). VBA enables programmability to controls added to the host using code that assumes the control’s type information is available through the registry. As such, the control’s type library needs to be registered on the system, even if the control was designed and installed using only Side-by-Side (SxS) for registry-less COM registration.
This behavior is “by design” in both VBA (VBE6.DLL) and Forms^3 (FM20.DLL). Control developers are asked to always register their control type library if they intend use of the control in Office applications or other VBA-enabled applications.
When an OCX is created in an Office application, the host requests VBA to wrap the control in a control extender and associate the control with a VBA project item so that events fired by the control can be handled by VBA macros. The code that handles control extension (*.exd) is the same code VB 6.0 uses for design-time extension when working with controls in VB6 projects (*.oca). This extender object allows the control site to add properties, method, and events to the control which the host implements for the control, but appear to the (VBA) programmer as single control object. To make programming easier, these added functions are mapped into a copy of the control’s type library with special DISPID for the extended functions. The control is then bound using DISPID-binding to the extended type library based on the type info mapped. For the extender to work properly, it will attempt to copy the control type library using information from the registry. This code to wrap the control’s type library is not SxS aware since it pre-dates SxS COM and is working outside of OLE32.DLL for access to the type info. As a result, controls that you use with VBA-enabled applications cannot be fully used in a registry-less configuration without problems.
An OCX needs to be fully registered in the registry to use it in Office at design time. This requirement is no different than the requirement of controls in the VB 6.0 IDE for forms development. At runtime, the control can be registered by SxS, and may run in an existing document if the VBA project is not modified. However, unlike VB6, VBA is not fully compiled and is never in a 100% guaranteed runtime state. Any change to the document that impacts a VBA project item, or any change to a macro code module, or any change/update of VBA, the host application, or any type library references added to the VBA project References, can and will reset the project back into design mode to be able to re-generate the p-code needed to run the macros. In such times, the control will require the extender (*.exd), and for that purpose, the control’s type library will need to be registered. This can be done by registering the control directly, or by registering a separate type library (*.tlb) outside the control if you have multple versions of the control you need running SxS but if they all share the same type info. If you need multiple versions of a control with different type info for each version running SxS, VBA does not support it and you cannot use that type of control in Office.
Altering the design of VBA to fully support SxS controls is beyond the current limits to the product. The code involved is shared with VB6, which is now frozen in its development phase. Microsoft does not plan to support SxS in VBA. However, the next generation of managed code controls and document parts used by VSTO and VSTA do not have this limitation with SxS registration, so customers needing long term solutions can look to those Office related technologies for future products.