TIP: Non-Visual ActiveX Components

Index

C++ Builder allows you to export ActiveX Controls from VCL controls. This is an extremely helpful ability, because when you develop ActiveX Components it is often useful to create a VCL form of the component first and export it to ActiveX late in the development cycle. This is because developing VCL controls to run in the C++Builder IDE is more straightforward than developing ActiveX controls. There is one major drawback, however: You cannot export anything to ActiveX that was not derived from TWinControl. So in effect, there is no built-in support for creating non-visual ActiveX Components. This page will help walk you through the process of creating such Components.

The first step is to create a TWinControl-derived class that mimics the behavior of TComponent. This is a real pain, because TComponent has a lot of nice features that are overridden by TWinControl.

  • It is hidden at run time.
  • It does not have a Window Handle.
  • It cannot be resized.
  • It displays an icon for our component in the form designer.

    • The second feature is one that we cannot regain. ActiveX requires that controls have a window handle. However, we can do something about the first.

    The trick to getting your ActiveX control hidden at run time is to set a special OLE flag telling OLE that you want the control hidden. While doing this is simple, it is not very well documented in C++Builder Help or MSDN as to how you should go about doing it. The newsgroups suggest that you add the following code to the declaration of the ActiveX implementation class that C++Builder generates:
    DECLARE_OLEMISC_FLAGS( dwDefaultControlMiscFlags | OLEMISC_INVISIBLEATRUNTIME )
    This notifies the OLE subsystem that the ActiveX control is non-visual in nature. Unfortunately, it requires the ActiveX developer to muck around with things after exporting our component. Yech. We tackle this by replacing a macro used by the ActiveX Wizard with one that does the DECLARE_OLEMISC_FLAGS. Because the wizard has to include our header before declaring the ActiveX class, we fool it into using our macro:

    #undef DECLARE_ACTIVEXCONTROL_REGISTRY #define DECLARE_ACTIVEXCONTROL_REGISTRY(progid, idbmp) \ DECLARE_OLEMISC_FLAGS(dwDefaultControlMiscFlags | OLEMISC_INVISIBLEATRUNTIME | OLEMISC_ONLYICONIC ); \ UPDATE_REGISTRY_METHOD( \ TAxControlRegistrar AXCR(GetObjectCLSID(), progid, idbmp, _GetObjectMiscStatus(), _GetVerbs()); \ hres = AXCR.UpdateRegistry(bRegister);)

    To make our control so that it cannot be resized, we do a number of things. In our constructor, we set our constraints so that TKaActiveComponent should always be 26x26 pixels. Unfortunately, there is a bug in the constraint code. Therefore in our paint procedure we always force the height and width to 26.

    Displaying an icon is perhaps the most burdensome aspect of this. We have to load a bitmap from a resource, then draw it do the control. Unfortunately, we can't easily tell where the resource is. If we use the HInstance variable, it is possible that we'll end up using the IDE's instance handle. If we use LoadLibrary or GetModule, then we are forced to distribute a .BPL for the component with our ActiveX control. I haven't found a clean way to avoid the .BPL re-distribution yet, but I'm working on it.

    See Also:

  • MSDN OLE_MISC Reference:
    http://msdn.microsoft.com/isapi/msdnlib2.idc?theURL=/library/psdk/com/oen_a2z_5vz7.htm
    (If Microsoft has broken this URL in any way, which is quite possible - even probable, please just search MSDN for the OLEMISC enumeration)