VisualCpp.org Collection of Visual C++ Stuffs

Why an ActiveX control written in ATL only fires its default event to a VB client. And how to overcome this.

If you write an ActiveX control in ATL, then if you specify that your ActiveX control will fire a non-default event, a VB client application will not be able to receive this event.

The reason for this is that a VB-written client application will only connect with the -default- event set of the ActiveX control.

The default event set is that which is specified in the ATL ActiveX control's class declaration, specifically the IProvideClassInfo2Impl template instance declaration :

IProvideClassInfo2Impl<[clsid], [iid of default outgoing dispinterface], ...>

Here, the second parameter is used to specify the IID of the default outgoing dispinterface.

If one needs the VB client app to connect with a different event set, then modify this IID accordingly.

 
_________________________
Tip Courtesy :-  Lim Bio Liong

Concerning making copies of and deletion of objects stored inside VARIANT parameters.

For a long time, I had a hard time trying to figure out the correct way to handle VARIANT parameters.

It is especially worrisome when VARIANT parameters hold objects like BSTRs, structures (VT_RECORD) and SAFEARRAYs.

Do we need to make copies of these before we insert them into VARIANTs ? And why ? Do we need to destroy these after we have inserted them into VARIANTs ?

It turned out that the answer is simple (albeit not trivial). It is analogous to the principles of reference counting for COM interface pointers. Basically :

1. In a COM method, when you need to pass an object (via a VARIANT) as an [out] parameter, you need to make a copy of it. This is similar to the fact that we AddRef() an interface pointer returned as an [out] parameter.

Hence it follows that once a copy of the object is made and inserted into the VARIANT, you do not delete it. It is the responsibility of the receiving client to delete it in its own time.

2. In a COM method, when you receive an object (via a VARIANT) as an [in] parameter, you can use it in whatever way you like but you must not delete it. This is similar to the fact that you do not Release() an interface pointer passed into a COM method as an [in] parameter.

Visual Basic is a very good tool to test whether your code follows COM standards as outlined above. If you write a COM object in VC++, and you have objects passed as [in] and [out] parameters, write a VB client code to test for robustness.

_______________________
Tip Courtesy :-  Lim Bio Liong