Existing ActiveX controls (formerly OLE controls) can be used on the Internet without modification. However, you may want to modify controls to improve their performance. When using your control on a Web page, there are additional considerations. The .ocx file and all supporting files must be on the target machine or be downloaded across the Internet. This makes code size and download time an important consideration. Downloads can be packaged in a signed .cab file. You can mark your control as safe for scripting, and as safe for initializing.
This article discusses the following topics:
You can also add optimizations, as described in ActiveX Controls: Optimization. Monikers can be used to download properties and large BLOBs asynchronously, as described in How Do I Update an Existing OLE Control to Use New ActiveX Control Features.
ActiveX controls are embedded in Web pages using the <OBJECT>
tag. The CODEBASE
parameter of the <OBJECT>
tag specifies the location from which to download the control. CODEBASE
can point at a number of different file types successfully.
CODEBASE="http://www.mysite.com/mycontrol.ocx#version=4,70,0,1086"
This solution downloads only the control's .ocx file, and requires any supporting DLLs to already be installed on the client machine. This will work for Internet Explorer 3.0 and MFC ActiveX controls built with Visual C++ 4.0 and 4.1, since Internet Explorer 3.0 ships with the supporting DLLs for Visual C++ 4.0 and 4.1 controls. If another Internet browser that is ActiveX control-capable is used to view this control, this solution will not work.
CODEBASE="http://www.mysite.com/trustme.inf"
An .inf file will control the installation of an .ocx and its supporting files. This method is not recommended because it is not possible to sign an .inf file (see Signing Code for pointers on code signing).
CODEBASE="http://www.somesite.com/acontrol.cab#version=1,2,0,0"
Cabinet files are the recommended way to package ActiveX controls that use MFC. Packaging an MFC ActiveX control in a cabinet file allows an .inf file to be included to control installation of the ActiveX control and any dependent DLLs (such as the MFC DLLs). Using a CAB file automatically compresses the code for quicker download. If you are using a .cab file for component download, it is faster to sign the entire .cab file than each individual component.
The CABinet Development Kit can be obtained from the Microsoft developers Web site, http://www.microsoft.com/workshop/. In this kit you will find the necessary tools to construct cabinet files.
The cabinet file pointed to by CODEBASE
should contain the .ocx file for your ActiveX control and an .inf file to control its installation. You create the cabinet file by specifying the name of your control file and an .inf file. Do not include dependent DLLs that may already exist on the system in this cabinet file. For example, the MFC DLLs are packaged in a separate cabinet file and referred to by the controlling .inf file.
For details on how to create a CAB file, see Creating a CAB file.
The following example, spindial.inf, lists the supporting files and the version information needed for the MFC Spindial control. Notice the location for the MFC DLLs is a Microsoft Web site. The mfc50.cab is provided and signed by Microsoft.
Contents of spindial.inf:
[mfc50installer]
file-win32-x86=http://activex.microsoft.com/controls/vc/mfc50.cab
[msvcrt.dll] - FileVersion=5,0,0,6164
[mfc50.dll] - FileVersion=5,0,0,6256
[olepro32.dll] - FileVersion=5,0,0,6068
The following example illustrates using the <OBJECT>
tag to package the MFC Spindial sample control.
<OBJECT ID="Spindial1" WIDTH=100 HEIGHT=51
CLASSID="CLSID:06889605-B8D0-101A-91F1-00608CEAD5B3"
CODEBASE="http://mysite/spindial.cab#Version=1,0,0,001">
<PARAM NAME="_Version" VALUE="65536">
<PARAM NAME="_ExtentX" VALUE="2646">
<PARAM NAME="_ExtentY" VALUE="1323">
<PARAM NAME="_StockProps" VALUE="0">
<PARAM NAME="NeedlePosition" VALUE="2">
</OBJECT>
In this case, spindial.cab will contain two files, spindial.ocx and spindial.inf. The following command will build the cabinet file:
C:\CabDevKit\cabarc.exe -s 6144 N spindial.cab spindial.ocx spindial.inf
The –s 6144
parameter reserves space in the cabinet for code signing.
Note here that the #Version
information specified with a CAB file applies to the control specified by the CLASSID
parameter of the <OBJECT>
tag.
Depending on the version specified, you can force download of your control. For complete specifications of the OBJECT
tag including the CODEBASE
parameter, see the W3C reference.
ActiveX controls used in Web pages should be marked as safe for scripting and safe for initializing if they are in fact safe. A safe control will not perform disk IO or access the memory or registers of a machine directly.
Controls can be marked as safe for scripting and safe for initializing via the registry. Modify DllRegisterServer to add entries similar to the following to mark the control as safe for scripting and persistence in the registry. The ActiveX Base Control sample, available from www.microsoft.com, contains helper functions for adding the necessary keys to the registry. An alternative method is to implement IObjectSafety.
You will define GUIDs (Globally Unique Identifiers) for your control to mark it safe for scripting and for persistence. Controls that can be safely scripted will contain a registry entry similar to the following:
HKEY_CLASSES_ROOT\Component Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}
Controls that can be safely initialized from persistent data are marked safe for persistence with a registry entry similar to:
HKEY_CLASSES_ROOT\Component Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}
Add entries similar to the following (substituting your control's class ID in place of {06889605-B8D0-101A-91F1-00608CEAD5B3}
) to associate your keys with the following class ID:
HKEY_CLASSES_ROOT\CLSID\{06889605-B8D0-101A-91F1-00608CEAD5B3}\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}
HKEY_CLASSES_ROOT\CLSID\{06889605-B8D0-101A-91F1-00608CEAD5B3}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}
If you want to use a licensed control on a Web page, you must verify that the license agreement allows its use on the Internet and create a license package file(LPK) for it.
A licensed ActiveX control will not load properly in an HTML page if the computer running Internet Explorer is not licensed to use the control. For example, if a licensed control was built using Visual C++, the HTML page using the control will load properly on the computer where the control was built, but it will not load on a different computer unless licensing information is included.
To use a licensed ActiveX control in Internet Explorer, you must check the vendor's license agreement to verify that the license for the control permits:
To use a licensed control in an HTML page on a non-licensed machine, you must generate a license package file (LPK). The LPK file contains run-time licenses for licensed controls in the HTML page. This file is generated via LPK_TOOL.EXE which comes with the ActiveX SDK. You can download the ActiveX SDK through the Microsoft Web site http://www.microsoft.com/activex.
To create an LPK file
To embed a licensed control on an HTML page
<OBJECT CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
<PARAM NAME="LPKPath" VALUE="relative URL to .LPK file">
</OBJECT>
For example, an HTML page that displays the Microsoft Masked Edit control is shown below. The first class ID is for the License Manager control, the second class ID is for the Masked Edit control. Change the tags to point to the relative path of the .lpk file you created earlier, and add an object tag including the class ID for your control.
If your control may be viewed on other Active enabled browsers — for example, Netscape using the NCompass ActiveX plug-in — you must add the <EMBED> syntax as shown below.
<OBJECT CLASSID="clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
<PARAM NAME="LPKPath" VALUE="maskedit.lpk">
<EMBED src = "maskedit.lpk">
</OBJECT>
<OBJECT CLASSID="clsid:C932BA85-4374-101B-A56C-00AA003668DC" WIDTH=100 HEIGHT=25>
</OBJECT>
See ActiveX Controls: Licensing an ActiveX Control for more details about control licensing.
Code signing is designed to identify the source of code, and to guarantee that the code has not changed since it was signed. Depending on browser safety settings, users may be warned before the code is downloaded. Users may choose to trust certain certificate owners or companies, in which case code signed by those trusted will be downloaded without warning. Code is digitally signed to avoid tampering.
Make sure your final code is signed so that your control can be automatically downloaded without displaying trust warning messages. For details on how to sign code, check the documentation on Authenticode™ in the ActiveX SDK and see Signing a CAB File. For more information on the Microsoft code-signing initiative, check http://www.microsoft.com/intdev/signcode/.
Depending on trust and browser safety level settings, a certificate may be displayed to identify the signing person or company. If the safety level is none, or if the signed control's certificate owner is trusted, a certificate will not be displayed. See Safety Levels and Control Behavior for details on how the browser safety setting will determine whether your control is downloaded and a certificate displayed.
Digital signing guarantees code has not changed since it's been signed. A hash of the code is taken and embedded in the certificate. This hash is later compared with a hash of the code taken after the code is downloaded but before it runs. Companies such as Verisign can supply private and public keys needed to sign code. The ActiveX SDK ships with MakeCert, a utility for creating test certificates, and two registry files, wvtston.reg and wvtstoff.reg, for specifying whether or not the browser should recognize test certificates as valid.
Containers determine the palette and make it available as an ambient property, DISPID_AMBIENT_PALETTE. A container — for example, Microsoft Internet Explorer 3.0 — chooses a palette that is used by all ActiveX controls on a page to determine their own palette. This prevents display flickering and presents a consistent appearance.
A control can override OnAmbientPropertyChange to handle notification of changes to the palette.
A control can override OnGetColorSet to return a color set to draw the palette. Containers use the return value to determine if a control is palette-aware.
Under OCX 96 guidelines, a control must always realize its palette in the background.
Older containers that do not use the ambient palette property will send WM_QUERYNEWPALETTE and WM_PALETTECHANGED messages. A control can override OnQueryNewPalette and OnPaletteChanged to handle these messages.
A browser has options for safety level, configurable by the user. Because Web pages can contain active content that might potentially harm a user's computer, browsers allow the user to select options for safety level. Depending on the way a browser implements safety levels, a control may not be downloaded at all, or will display a certificate or a warning message to allow the user to choose at run time whether or not to download the control. The behavior of ActiveX controls under high, medium, and low safety levels on Internet Explorer is listed below.
See Also Internet: Where Is..., ActiveX Controls: Licensing an ActiveX Control