ActiveX加载方法的差异

Question

I have a custom ActiveX control that is used by web pages in IE. It loads just fine and is accessible to Javascript running in the page if I load it via an OBJECT tag like this:

<object id="ccl" codeBase="ccl.cab" classid="CLSID:12372D58-F10C-11CF-B7A9-0020AFD6A362" NOEXTERNALDATA="true"></object>

But if I try to load it via new ActiveXObject() like this:

var x = new ActiveXObject('myObj.abc');

I get the error "Automation server can't create object".

I thought these two methods of loading a document were equivalent in the case where the ActiveX control has already been installed. But apparently they're not. Can anyone help me understand under what conditions the OBJECT tag method would succeed while the new ActiveXObject method would fail? I have double-checked to make sure the progID I'm passing into new ActiveXObject() is correct and appears in the registry under HKEY_CLASSES_ROOT\\CLSID as it should. Thanks in advance for any ideas.

Answer 1

I can't find a supporting link but IE (at least older versions like 6 and 7) will not let you fire events from controls created with new ActiveXObject(). There may be other differences... internally in IE the code paths are very different. I don't know of a complete guide.

You could set breakpoints in your SetSite() method and see if it's getting called. Also verify your registration is correct.

Answer 2

The startup for objects created in an object tag or an object created with ActiveXObject are different -- they would have to be, when you think about it, since one doesn't have a window to draw in. As is hinted here an object tag instantiates the control as a IObjectWithSite (by mshtml.dll), whereas new ActiveXObject instantiates it as an IOleObject (by jscript.dll).

This means that with ActiveXObject, SetSite is called and with an object tag SetClientSite is called . Also, you will not get any IPersistPropertyBag calls, nor any InPlaceActivate, etc calls with ActiveXObject.

It is of course possible to write a control to support both, as can be seen from the FireBreath source code I linked.

A more complete explanation (from someone who understands it better) can be found here .

Answer 3

Thanks to those who submitted the previous answers. While they didn't provide a solution to my problem, they set me on the right track to find the answer myself.

The problem was that my ActiveX control used the implementation of IObjectSafety provided by Microsoft's SiteLock template (IObjectSafetySiteLockImpl). As the SiteLock documentation states:

If you create an ActiveX control via script (instead of using the tag), then the scripting host is responsible for setting the site and not the browser. Neither JavaScript nor the > VBScript engine will set the site until after it has decided that you are safe, so you cannot create a site-locked control that way.

In this case my ActiveX control did not need the SiteLock functionality, so I replaced IObjectSafetySiteLockImpl with the standard ATL implementation of IObjectSafey (IObjectSafetyImpl).