Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

INFO: Hosting ActiveX Controls in a Netscape Plug-in


View products that this article applies to.

This article was previously published under Q282168

↑ Back to the top


Summary

In order to reuse ActiveX controls, which are developed for use in Internet Explorer, in other browsers that do not support them, you may want to create a Netscape plug-in that hosts the ActiveX control. This article describes general guidelines on how to host ActiveX controls in a Netscape plug-in and is divided into the following sections:

↑ Back to the top


More information

Framework Overview

It is helpful to review the two component frameworks, ActiveX controls and Netscape plug-ins, to note their similarities and differences and evaluate what is needed to create a functional design.

Netscape Plug-ins

Netscape plug-ins were among the first component frameworks to be used in Web development. On the Microsoft Windows platform, plug-ins are constructed as standard Win32 dynamic-link libraries (DLLs) that rely on a series of predefined entry points to expose functionality. They are given a window handle (HWND) by their container, which they then subclass to receive user interaction and operating system notifications through Windows messages.

ActiveX Controls

ActiveX controls are lightweight, reusable Component Object Model (COM) components. They are given a site (in the form of a COM interface pointer) by their container, and they use COM methods and interfaces to communicate with the container. ActiveX controls are smaller, simplified versions of object linking and embedding (OLE) controls (as defined by the OLE Controls 96 specification). ActiveX controls do not necessarily have an HWND; they can be windowless, in which case their container forwards them the information that is normally conveyed through Windows messages.

Design Guidelines

Basically, a Netscape plug-in that hosts ActiveX controls must provide a way to translate the information and requests that are relayed as Windows messages into COM method calls.

The single most important (and difficult) task for the plug-in developer is to implement all of the COM interfaces that are required for an ActiveX control container. The following interfaces are implemented in a standard ActiveX control container:
  • IOleInPlaceFrame
  • IOleInPlaceUIWindow
  • IOleInPlaceSite
  • IOleClientSite
  • IAdviseSink
  • IOleControlSite
  • IDispatch
  • IPropertyNotifySink
If the plug-in is designed to host only one ActiveX control whose behavior you control, you may omit (or only partially implement) some of these interfaces. However, if the plug-in is designed to be a general purpose control container, it is critical that you implement these interfaces fully and correctly to allow maximum interoperability between the plug-in and the ActiveX controls that it hosts.

After you implement all of the required COM interfaces, the plug-in instantiates the control as any other container does: it initializes the COM Library through the OleInitialize function and creates an instance of the control (through CoCreateInstance, CoGetClassObject, and so on). When the plug-in ends, it also destroys the control instance and uninitializes the COM Library.

Potential Problems

Because this is such a complex design, you may encounter several problems:
  • Internet Explorer provides a rich set of COM interfaces, the IHTML* interfaces, to programmatically manipulate the Document Object Model (DOM) of the current HTML page. Many ActiveX controls take advantage of this functionality to interact with the page on which they are hosted. Other browsers may not provide this functionality; as a result, the control may generate errors.
  • Similarly, Internet Explorer exposes the IWebBrowser2 COM interface through which ActiveX controls can interact with it programmatically. This interface may not be present on other browsers; as a result, the control cannot access this functionality.
  • Internet Explorer allows script code on an HTML page to communicate with an ActiveX control on the page. To do this, Internet Explorer translates script calls that are made to the <OBJECT> tag that hosts the control into IDispatch calls (such as GetIDsOfNames and Invoke) that are delegated to the control. Although other browsers may use the plug-in as an intermediary to achieve a similar functionality, the browser must somehow notify the plug-in of a script call. This functionality is obviously not guaranteed.

↑ Back to the top


References

For more information on the Netscape Plug-in API Reference, see the following Netscape Web site: For more information about developing Web-based solutions for Microsoft Internet Explorer, visit the following Microsoft Web sites:Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

↑ Back to the top


Keywords: KB282168, kbinfo, kbctrl

↑ Back to the top

Article Info
Article ID : 282168
Revision : 4
Created on : 10/25/2006
Published on : 10/25/2006
Exists online : False
Views : 334