Download source - 4.53 Kb

Introduction

As a result of the Eolas patent, Microsoft has changed the way that Internet Explorer loads ActiveX controls. All interactive controls which are embedded directly within a page must now be activated before they can be used.

ActiveX activation in Internet Explorer

An article on MSDN[^] provides instructions on a workaround for this change. The work-around involves creating an external script file for every control instance, which may not be practical in a dynamic site.

Terrence Sheflin, of Dundas Software, recently posted an article[^] and a control which attempts to make the workaround more reusable. However, the control has several problems:

The control creates a new JavaScript file for every instance created:

With multiple instances on a page, only the last control is rendered.
With multiple requests, data from one request may be overwritten with data from another request. If the control contains sensitive information, this could result in security problems.
The security settings on the web server must be modified to allow ASP.NET to create files in the root folder of the application.

The control modifies the page flow:

For example, if the control is applied to TargetControl, a page containing:

<form runat="server">
    <h1>Page Heading</h1>

    <div class="container">
        <xyz:someControl id="TargetControl" runat="server" ... />
    </div>
</form>

will actually be rendered as:

<form runat="server">
    <script src="/embed.js"></script>  <-- This line renders TargetControl

    <h1>Page Heading</h1>
    <div class="container">
        
    </div>
</form>

The control cannot be used declaratively:

The control does not expose a parameter-less constructor, so it cannot be used declaratively. Instead, the code in the Page_Load method must locate the target control and create an instance of the AutoActivateControl to wrap it. If the target control is within a templated parent such as a Repeater, this involves a call to FindControl for each instance of the template created.

Other issues:

If script is disabled, nothing will be displayed.
HTML OBJECT tags cannot be used unless that have the runat="server" attribute added.
The rendered JavaScript output is not properly escaped - only the carriage return and line-feed characters are replaced.
The control does not use the correct HtmlTextWriter type for the current browser.
The control affects all browsers, not just Internet Explorer.

A better way...

Internet Explorer doesn't actually need a unique external JavaScript file for every control instance. Instead, you can create a single external JavaScript file with a single method:

window.AutoActivateControl_WriteObjectElement = 
                         function(elementData) 
{
    if ("string" != typeof(elementData) || 0 == elementData.length) return;
    document.write(elementData);
};

You can then call this method from script within the page, and the control will be rendered without activation.

The original control uses the PreRender event to capture the output of the target control, and the RegisterClientScriptBlock method to include the output in the page. As a result, the control is rendered immediately after the opening <form runat="server"> tag, which is outside of the normal page flow.

The solution is to create a container control which will contain all of the controls to be modified. It can then use the RenderChildren method to capture the output and override the Render method to render the output in the correct location. With this solution, even static HTML can be targeted, so <OBJECT> tags no longer require the runat="server" attribute.

The new control is designed to be used declaratively, and can be used anywhere on the page. It will only affect browsers which support ActiveX controls (as detected by the HttpBrowserCapabilities class), and will render a <noscript> tag for situations when script is disabled.

Using the control

Compile the control using one of the provided files:
- build_VS2003.bat for .NET 1.1;
- build_VS2005.bat for .NET 2.0;
- AutoActivateControl_VS2005.csproj for Visual Studio 2005;
Add the assembly to your bin folder;
[.NET 1.1] Copy the JavaScript file to the root of your application;

<%@ Register
    TagPrefix="tri"
    Namespace="Trinet.Web.Utilities"
    Assembly="Trinet.Web.Utilities.AutoActivateControl"
%>

Add the control as a parent of any control you want to target:

<tri:autoActivateControl runat="server">
    <xyz:someControl id="TargetControl" runat="server" ... />
    <object classid="clsid: ... />
</tri:autoActivateControl>

In .NET 2.0, the script will be loaded from an embedded resource, so it is not necessary to distribute the JavaScript file. If you want to override this behavior, you can set the UseScriptResource to false.

If you want to move the JavaScript file to a different location, you will need to set the ScriptLocation property to the new path:

<tri:autoActivateControl runat="server" 
      scriptLocation="~/scripts/AutoActivateControl.js">

An alternative solution

As Mark Werner and FunkyMonkey have pointed out, it is also possible to avoid control activation by modifying the HTML DOM from an external script file [^] once the page has loaded. This method works with all pages, not just ASP.NET, and only requires a single line addition to each page.

History

1 June 2006 - Initial version.
6 June 2006:
- Fixed a typo in the TagPrefix attribute in the AssemblyInfo.cs file;
- Fixed a typo in the Assembly attribute of the <%@ Register ... directive;
- Added a link to an alternative solution;

Avoiding ActiveX Activation in IE