Some weeks ago, we released ECMerge ActiveX.
One of our goals was to let ECMerge work in all common versions of Internet Explorer (we test it on IE 6, 7 and 8).
ECMerge ActiveX worked in IE 6 without a problem, OK, not that easy to end a multi threaded application placed in a DLL in particular because of DLL load/unload events mutexes.
Imagine what happened in IE7 and 8… no more JavaScript events with the <script for=”"> notation, attachEvent which does not work either. Finally the VBScript approach works (i.e. <script language=”vbscript”>Sub Object_EventName()</script>).
ECMerge ActiveX supports the full panel of features of ECMerge, you can differentiate folders and an event called AddView is fired each time the application should open a document… this time the security features of IE come in.
As of Internet Explorer 8, there is a new security feature which run ActiveX plug-ins in a separate process depending on the trust level that it gives to the ActiveX… it means that two instances of the same ActiveX with different trust levels will be actually run in different processes. This is a problem since the ECMerge ActiveX expects the documents that it creates to be viewed in the process of creation. ECMerge verifies that and fails nicely if the document is not hosted by the right process. One user side solution: ensure that the FHAxMerge component which create a FHAxMergeDocument object and the one opening it are in the same page.
If you want to see ECMerge ActiveX in action:
http://www.elliecomputing.com/Products/merge_component_onlinedemo.asp
Regards
Armel
For IE 8, are you saying IE 8 create a brand new PROCESS for ActiveX control? Did you confirm this or see it in Microsoft document? Can you give a link to the document?
If this is the case, it is much different from previous IEs. And BHOs writtern for previous IEs may have problem working with IE8.
It is our experience in fact: when you run IE with our ActiveX IE spawns immediately two processes, the UI and the ActiveX holder process. When you click on a script playing with the ActiveX and accept to trust it, that process becomes “trusted ActiveX holder”. Now run the same page in another IE, a third process spawns: the “untrusted ActiveX holder”… but nothing can re-unify the two ActiveX holders if you make the second trustable (in ActiveX object can definitely not jump from a process to another).
This problem is exhibited with radio players as well: run IE, start playing, run any other website aside, close first window with widget playing… and it continues playing! (because the run-time engine playing the sound is in the ActiveX holder process not in the UI process). the site http://www.rtl.fr at this date (2009/07/10) exhibits the problem.
I am pretty sure this behaviour is explained in MSDN, I could not find the document again though.
Regards
Armel
I think that you can find some of the information here:
http://www.microsoft.com/windows/internet-explorer/readiness/developers-existing.aspx#lcie
they explain the ‘tab’ processes and ‘process merging’ and so on…
Regards
Armel