Have you ever received a call from a customer stating that when your ActiveX Object are being created in HTML pages they get an annoying "Control may be unsafe for use" dialog? Ever wanted to know how to prevent this from happening?

This article will try to show an example of how to provide support in your COM applications for use in pages displayed inside Microsoft ® Internet Explorer ® which removes the display of warning dialogs to users about initialisation of potentially unsafe items.

By default, ActiveX controls or COM Automation Servers that are going to be used from HTML files displayed inside Microsoft ® Internet Explorer ® will have a few difficulties when initially used – in the form of annoying dialogs about their safety.  This is due to security elements built into Internet Explorer ® which control the way these COM items are initialised and then displayed.

Microsoft ® provides us with two ways to notify Internet Explorer ® that our software is actually safe for use inside the browser display.  These are:

1) Using the Component Categories Manager
2) Supporting the IObjectSafety Interface

Internet Explorer ® refers to the registry prior to attempting to load your control in order to determine if it is safe for use.  Initially it will refer to the Component Categories Manager to determine if information is available about your components safety.  If it can not find the information here, it will try to determine if your control supports the IObjectSafety interface instead, and will query the method SetInterfaceSafetyOptions of this interface to establish if your control will be safe for initialisation.

Well, which one do we implement?  Well, the option is entirely yours.  I will show you how to implement either, so you can chose the one you prefer, or both if you want to be completely secure for potential changes to this process in the future versions of Internet Explorer ®. (Not that I am overly cautious! J )


Using the Component Categories Manager
======================================

Using the Component Categories Manager to mark the control creates a sub-key called “Implemented Categories” which itself then will have sub-keys to indicate the support for the control.  In our case we will create sub-keys for Safe Initialisation, which relates to the GUID CATID_SafeForInitializing, and Safe for Scripting, which relates to the GUID CATID_SafeForScripting.  In some other versions of Delphi (namely 3) these ID’s, and the definition for IObjectSafety, don’t seem to exist in the ActiveX or other COM related units.  In which case I have added this information into the unit I have created and included in an archive to accompany this article.

In addition, the system registry contains a Component Categories key, which lists – as subkeys – the categories of functionality implemented or required by applications or components installed on the current machine.  We must ensure that these items are also registered.  To do this we create an instance of the Component Categories Manager, and obtaining the ICatRegister interface it supports.  With this interface we must call the RegisterCategories method passing it a CATEGORYINFO structure that has been initialised with the required information.  To clarify this in a simpler form, I have again included an example in the accompanying archive.

The catch with the use of the Component Categories Manager is that we really need to override the functionality of the Factory responsible for the object being created, as this is the element responsible for registration information mainly for Automation Servers.  We can do this by overriding the UpdateRegistry method of the factory, and performing either registration or un-registration during the appropriate call.  For In-Process Servers (COM DLL’s) and for OCX controls we have another approach available to us.  This is to override the functionality of DllRegisterServer and DllUnRegisterServer to perform the required registration.  However, as part of this registration process we really need to invert the order of the required registration.  We must actually create the required category, and then register the category as being implemented by the control.


Implementing IObjectSafety
==========================

This interface is the mechanism that any COM container can use to ask a control to make itself safe, or request currently information about its initialisation or scriptable capabilities.  This information is requested by the bit-flags defined as:

INTERFACESAFE_FOR_UNTRUSTED_DATA
INTERFACESAFE_FOR_UNTRUSTED_CALLER

Microsoft ® has also reserved additional growth in this area to provide for possible future additions.  I like forethought!

The IObjectSafety interface only provides two methods for use, GetInterfaceSafetyOptions and SetInterfaceSafetyOptions.  Obviously, the Get method allows a container to query the control for its current support of the above flags, whilst the Set makes a request to the control to prepare itself for either or both safe initialisation and scripting.

The unusual thing here is that whilst some containers will call the Get method to determine the level of support provided by the control, Internet Explorer ® will not.  Internet Explorer ® actually calls the Set method prior to the initialisation of the control and, if the control supports scripting, then it calls this method again.

An example showing the implementation of this interface is included in the accompanying archive to demonstrate its use.


Other Notes
===========

Whilst I have provided a unit here that includes the following routines used in this example, please note that I have recently added these to the JEDI Code Library (JCL) also.  This means that some future release of the JclCOM unit will also contain these useful routines:

· CreateComponentCategory
· RegisterCLSIDInCategory
· UnRegisterCLSIDInCategory

Attached to this article is a ZIP file containing this text and a complete example (tested in Delphi 5 & 6, but should work for 3+)


Additional References:
======================

Below are references used in the creation of this article, and also other examples provided by Microsoft to demonstrate how to use or implement these approaches.

Designing Safe ActiveX Controls
http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/safety.asp

Safe Initialization and Scripting for ActiveX Controls
http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/safety.asp

Internet Explorer (Programming) Support Center
http://support.microsoft.com/default.aspx?scid=fh;EN-GB;iep

HOWTO: Implement IObjectSafety in Visual Basic Controls (Q182598)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q182598

HOWTO: Mark MFC Controls Safe for Scripting/Initialization (Q161873)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q161873

SAMPLE: SafeCtl.exe Implements IObjectSafety in ActiveX Control (Q164119)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q164119