The following is advise from Brian Muth MVP, taken from the MSDN Forum for Visual C++ Language :
To use the <OBJECT> tag (to create a COM object), the ATL COM object needs to implement the IObjectWithSite interface. This can be done quite trivially, since ATL gives you the IObjectWithSiteImpl<> template. Just add the following line to your list of inherited classes:
The following advise is for Internet Explorers that features tabs :
In order to debug a web page for the purpose of stepping into a COM object or an ActiveX created within HTML code, it is not sufficient to simply start iexplore.exe.
This is because the main IE process may spawn additional iexplore.exe for every tab.
Hence one way to debug into a HTML page is as follows :
1. Start IE.
2. Load the web page.
3. Determine the Process ID (PID) of the iexplore.exe that is hosting the web page.
4. Debug into the running process of that iexplore.exe by using the "Attach To Process" facility.
5. Refresh the web page.
According to the Web Design Group's web page for the "OBJECT" tag (<a href="http://htmlhelp.com/reference/html40/special/object.html"></a>) :
The CLASSID attribute may be used to specify an implementation for the object. Java applets, Python applets, and ActiveX controls all provide implementations for the embedded object, and so are specified with the CLASSID attribute...
Some examples of the use of the CLASSID attribute are also listed :
Hence, the string value contained inside a CLASSID attribute need not always specify an ActiveX. It may be anything that can be interpreted by the browser. For example, the "CLSID:" prepending string is interpreted by the IE browser to expect the GUID of an ActiveX control to follow.
The following case is extracted from the MSDN Visual C++ Forum :
Posted by Anand K Reddy :
<OBJECT classid="2D0B18FB-673F-4B90-865F-3EC067C9DEA9" id="a"></OBJECT>
myobject = new ActiveXObject("SAMPLEACTIVEX.sampleActiveXCtrl.1");
if(myobject != null) alert("Object Found");
alert("Result is Null");
The CLASSID attribute remains invalid and so your ActiveX will not get created.
2. Next, comes the problem with "myobject" :
myobject = new ActiveXObject("SAMPLEACTIVEX.sampleActiveXCtrl.1");
The issue has to do with the calling of the IPersistPropertyBag::InitNew() method of your MFC ActiveX Control. This interface method is called by the MSHTML.DLL code within IExplorer.exe.
3. The IPersistPropertyBag::InitNew() method is implemented for you by MFC via the COleControl::XPersistPropertyBag::InitNew() method. Your MFC class would have been derived from COleControl and so this function is already embedded within your MFC class.
3. Inside COleControl::XPersistPropertyBag::InitNew(), you will notice a call to set COleControl::m_bInitialized to TRUE. This is important as we will see later.
4. Now, when any of your control's methods is called, the JScript engine will first get MSHTML to obtain the ID of your method. This is the essence of late binding. Hence, if MyAdd() is to be invoked, JScript will need to know the ID of the MyAdd() function which in your ActiveX control would be DISPID_MYADD.
5. MSHTML will inquire of your ActiveX the ID of MyAdd() by calling your ActiveX control's IDispatch::GetIDsOfNames() method. This is implemented for you by MFC with the function : COleDispatchImpl::GetIDsOfNames().
6. After obtaining this ID, the IDispatch::Invoke() method will be called. The IDispatch::Invoke() method is implemented for your ActiveX by the COleDispatchImpl::Invoke() method. It is here that your MyAdd() function should get called. However, there is a line within COleDispatchImpl::Invoke() that goes like this :
// allow subclass to disable Invoke
This is the function COleControl::IsInvokeAllowed() and it is the "archilles tendon" of your problem.
8.1 By declaring "myobject" and then setting it to a new ActiveXObject(), a brand new instance of your ActiveX control will be created. The "a" object will remain but it will not be used. The calling of IPersists* interface methods of your ActiveX control will not be called.
8.2 "myobject" will end up without its COleControl::XPersistPropertyBag::InitNew() ever being called which will result in its COleControl::m_bInitialized remaining FALSE. This results in the COleDispatchImpl::Invoke() function returning E_UNEXPECTED.
Hence my recommendation that you use the "a" object and remove the declaration and use of "myobject".
The following is take from a post by Nibu Thomas (MVP) in the Microsoft Visual C++ Language forum :
There is only one way to delete properly and it depends on the way you allocated.
So if you allocate with
int* ptr = new int
delete  ptr; // then delete like this
then you got to delete with delete  ptr. Don't get fooled by what you see in the output window of visual studio. Because visual studio places a marker around at the beginning of the memory block to check whether delete has been called or not (it's provided just to help). It does not differentiate between 'delete ' and 'delete'.
So if you allocate with
int * ptr = new int;
delete ptr; // then delete like this
To get rid of these allocation and de-allocation headaches use
There was recently a question posted on the COM forum here at CodeProject and it involved a temporary VARIANT object being created (in a VB client code) to fill an [in, out, optional] VARIANT* parameter of a method call.
The person who posted the original question was one GuimaSun and his COM server code was listed as follows :
VariantClear( p );
VariantInit( p );
p->vt = VT_BSTR | VT_BYREF;
BSTR *pBSTR = new BSTR;
*pBSTR = SysAllocString( L"abc" );
p->pbstrVal = pBSTR;
His VB client code was :
For i = 1 To 1000
Dim myInt As Integer
myInt = 3
ret = client.CallService(myInt)
Apparently, his COM server code was changing the Variant Type of the input VARIANT pointer "p" and assigning it to contain a BSTR.
His VB code experienced memory leaks due to the BSTR (created inside his COM CallService() method) not being ::SysFreeString()'ed.
After much discussion with several members of the forum, Vi2 came up with a code suggestion for GuimaSun as follows :
STDMETHODIMP CDCSClient::CallService(/*[in,out]*/ VARIANT *p)
if (V_VT(p) == (VT_VARIANT | VT_BYREF))
// only here you can change the type of passed variable (see VB example below)
VARIANT *p2 = V_VARIANTREF(p);
p2->vt = VT_BSTR;
p2->bstrVal = SysAllocString( L"abc" );
Dim v As Variant
v = 1
Debug.Print TypeName(v) & " " & v
Debug.Print TypeName(v) & " " & v
Basically, only a VARIANT of Variant Type (VT_VARIANT | VT_BYREF) can be modified to be of a different VT.
3.1 This avails all types that have already been compiled in another type library ("msado15.tlb" in the above example) to the current IDL file.
3.2 Note that an [importlib] statement can only appear inside a [library] statement. Furthermore, the imported type library, together with the generated type library of the current IDL file, must be available at runtime for the application.
3.3 Now, unlike the [import] statement, where a #include <header file of the imported IDL> directive is generated inside the .h file the current IDL, an [importlib] statement does not cause the generation of such an #include statement.
3.4 Because of this, the cpp_quote IDL keyword should be used to #include any necessary header files in the generated .h file for the current IDL. For example :
1. The CCmdTarget class implements COM interfaces via the declaration of macros. These include DECLARE_INTERFACE_MAP(), BEGIN_INTERFACE_MAP(), INTERFACE_PART() and END_INTERFACE_MAP().
2. CCmdTarget also implements its own version of QueryInterface() named InternalQueryInterface().
3. In order to be generic, InternalQueryInterface() is coded with the help of the interface map which is accessed via the function GetInterfaceMap(). The interface map itself is an array of AFX_INTERFACEMAP_ENTRY structures. Each AFX_INTERFACEMAP_ENTRY structure indicates a specific COM interface that the CCmdTarget class exposes.
4. InternalQueryInterface() looks up this array of AFX_INTERFACEMAP_ENTRY structures to determine whether an interface is supported.
1. The API to use for connecting to the event source of an object to a sink in a client application is AfxConnectionAdvise().
2. Assuming an event source interface that is purely IDispatch-based, we can implement an event sink (using MFC) via a CCmdTarget-derived class.
3. Listed below are the basic requirements of a sink :
3.1 It must implement IDispatch.
3.2 It must acknowledge the support of the DIID (dispatch ID) of the outgoing event interface.
3.3 It must implement the methods of the outgoing source interface.
4. Based on the requirements listed above, we can proceed to create an eventsink that is based on code provided by MFC. The following are the salient points of such a class :
4.1 It must derive from CCmdTarget. This is due to the CCmdTarget class' internal support of the IDispatch interface (as per requirement 3.1). The CCmdTarget's IDispatch implementation is achieved via a tiny embedded class named XDispatch. An instance of this emdedded class (m_xDispatch) is declared inside CCmdTarget. m_xDispatch must first be initialized via the CCmdTarget::EnableAutomation() function. This should be called inside the constructor of the sink class.
4.2 It must include the DECLARE_INTERFACE_MAP() macro in its class definition. This indicates to the MFC framework that this class will have a custom interface map. Through the interface map, we declare the various interfaces (including any source Dispatch interface) supported by the sink class (as per requirement 3.2). Via the macros BEGIN_INTERFACE_MAP(), INTERFACE_PART() and END_INTERFACE_MAP(), we declare that the sink class implements the source Dispatch interface.
4.3 It must include the DECLARE_DISPATCH_MAP() macro in its class definition. This macro indicates to the framework that this class will provide a dispatch map to expose IDispatch-based methods and properties. Through the diapatch map, we declare the various methods and properties exposed by the sink class. The methods must of course correspond with the methods of the source IDispatch interface (as per requirement 3.3).
The macros used are : BEGIN_DISPATCH_MAP(), DISP_FUNCTION(), DISP_PROPERTY(), END_DISPATCH_MAP().
5. In a call to AfxConnectionAdvise(), the 3rd parameter must be the IUnknown interface pointer to the event sink. To get this IUnknown interface pointer, the entry point function is the CCmdTarget::GetIDispatch() function. Call this function using the sink object. From the IDispatch interface pointer returned from CCmdTarget::GetIDispatch(), we can QueryInterface() it for an IUnknown interface pointer.
Note the following about asynchronous interfaces :
1. An asynchronous interface must only derive from IUnknown directly.
2. If an asynchronous interface is derived from another interface that derives from IUnknown, calls to an asynchronous method may not go correctly (e.g. a different method may end up getting called).
3. If an asynchronous interface is derived from IDispatch or is derived from another IDispatch-derived interface, it will not be possible to obtain the asynchronous interface from ICallFactory::CreateCall().
If a COM object (written in C++) is to implement 2 interfaces with a common name and common number of parameters and parameter types, then the following are options :
1. Use interface shims to supply 2 separate implementations of the 2 methods.
2. Supply only one method. This way, both interfaces share one implementation for the common method.
If a COM object (written in C++) is to implement 2 interfaces with a common name but different number of parameters or different types of parameters , then the following assertion holds :
1. The C++ compiler will properly sort out the appropriate method for each interface's vtbl. In other words, nothing need be done. The C++ compiler will ensure that the correct method will be called according to which interface is used.
Note the following findings about asynchronous interfaces :
1. An interface that is marked to be asynchronous must be derived from IUnknown. It cannot be derived from IDispatch.
2. A C++/ATL implementation which has #import'ed the originating IDL may experience compilation errors e.g. "MIDL2320 : conflicting optimization requirements, cannot optimize : [Procedure '...']" :
2.1 The cause of the problem has to do with the fact that the asynchronous interface most likely was declared outside of the "library" statement in its original IDL file.
2.2 This indicates to the compiler (compiling the current implementation) that the asynchronous interface will not be using Type Library marshaling (i.e. standard marshaling that uses the Type Library for information instead of any proxy/stub DLL).
2.3 The marshaling for the asynchronous interface will be done via a proxy/stub DLL.
2.4 We currently do not why the compilation error is issued. However, we do have a soluton : place an "importlib" statement inside the "library" statement of the current implementation. It must import the type library of the original IDL file.
2.5 This will avert the compilation problem.
3. A good news about asynchronous interfaces is that it can be implemented in VB. However, the VB implementation must be ActiveX EXE based.
* If you define an interface in a Type Library and implement it in Visual Basic, no problem.
* For example, if you define an interface ITestInterface in a Type Library and then have your VB ActiveX project reference this type lib, the following statement goes fine :
* However, if you define a source (i.e. event) interface in a Type Library and try to have a Visual Basic ActiveX raise its events via RaiseEvent statements, not possible.
* For example, if you define a dispinterface _ITestEvents with event Event01() in a Type Library and then have your VB ActiveX Project raise it as follows :
The VB Compiler will complain of an unidentified event.
If you try to raise it as follows :
The compiler will not complain but it still won't work. The problem is that _ITestEvents will not be recognized as being a source interface of the ActiveX.
* If we try to define the events of _ITestEvents in the declaration of the ActiveX itself, e.g. :
Public Event Event01()
The ActiveX will then declare a source interface for itself and Event01() will be absorbed into this default source event set, i.e. you will find the following declarations when you observe the TLB generated for the ActiveX :
Q : For marshelling between apartments, are the stub/proxy code generated automatically by COM Runtime ? Is thre a need for us to explicitly write stub/proxy code by ourselves ?
A : If your interface methods and properties strictly uses types that are automation-compatible (i.e. the types that can be found in a VARIANT structure), then the standard proxy and stub code as contained in OLEAUT32.DLL (the standard Proxy/Stub DLL for Ole Automation) will be used. Yes, in this case, there is no need to explicitly program proxy/stub code.
However, please take note of the following :
1. The type library containing your interface definitions must be registered. This type library will be loaded by OLEAUT32.DLL at runtime in order to understand the signatures of your methods (parameter types, return types) for correct marshaling/unmarshaling and method calls across apartments.
2. The interface definitions involved in marshaling must be contained in the type library. In order for this to happen, the interface definition must either be defined inside the "library" statement in the source IDL file, or it is at least referenced inside the "library" statement. Otherwise, marshaling will fail. One of the possible failure code is TYPE_E_ELEMENTNOTFOUND (0x8002802BL).
3. Most importantly, the interface definition must be attributed with either "oleautomation" or "dual" or that it is by definition a "dispinterface". This will ensure that the Type Library Marshaler (i.e. OLEAUT32.DLL) recognizes the interface as being OLE-AUTOMATION compatible. Failure to comply will result in failure in marshaling. One of the possible failure code is E_FAIL (0x80004005L).
Last Visit: 31-Dec-99 19:00 Last Update: 19-Dec-14 1:12