Server Control for Injection of Client ActiveX Control

• Download source - 17.47 KB

Introduction

Internet Explorer has had the ability to display Windows controls within the context of a web page by utilization of the HTML <object> tag. These were originally ActiveX controls, but since the advent of .NET, this functionality has been expanded to allow ANY WinForms control and functionality to be embedded in a web page.

This article presents an ASP.NET Web Custom Control which wraps all the necessary code to inject an ActiveX control onto a page viewed via Internet Explorer.

Along with the injection code, this control adds the ability to reference the public properties exposed by the ActiveX control on the server side. Thus this control allows you to set this property in server code, and then read back any changed value on postback.

Since this control was originally written to encapsulate the injection of .NET based controls - additional handling is added to aid the developer in correctly setting up the control. This article will concentrate on .NET controls.

Background

For a background in the injection of WinForms controls, please see:

• DHTML and .NET: Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer, and
• Hosting .NET Windows Forms Controls in IE

Please make note of the security considerations of the utilization of .NET WinForms controls within Internet Explorer.

This control came about as a result of a requirement by one of my clients to create an easily accessible input form, which would allow users to paste screen shots in order to facilitate trouble shooting efforts. The requirements of "easily accessible" pointed to a web solution, where as "paste screen shot" pointed to a WinForms solution. These two were fundamentally at odds until the articles above presented themselves. (Silverlight was not even an option here, though Flash may have been possible.)

Please note: Since this solution was to be only available within a corporate network - with Internet Explorer being the only supported browser, this course was completely viable, outside of a controlled network (or at least a controlled user base) - this solution would be inappropriate.

Using the Code

In order to piece this control together, you need to have a concept of the components involved. These are:

1. A WinForms based User Control
2. The bc.WebControls.ObjectTag control which I have written
3. An ASP.NET website/ web app with a reference to the bc.WebControls project, and the binary DLL within a directory under the web site (not the \bin folder)
4. A webpage under the site which includes the bc.WebControls.ObjectTag control

The attached project source code contains all of these elements. I'll now step through each of the elements in the order as above.

1. The Client ActiveX Control Project - bc.WebClientControl

This project contains a single UserControl (InputControl) - this is only an example - if you were looking to use the bc.WebControls.ObjectTag, you would be creating a control for your own purpose. Keep in mind that this control can contain any WinForms element - and can be coded as any standard WinForms control.

In my example, the InputControl exposes 3 public properties (besides those inherited from System.Windows.Forms.UserControl) - InputText, SelectedValue & InputPrompt - and these properties are in-turn, bound to UI elements within the control.

/// <summary>
/// The value entered by the user
/// </summary>
public string InputText
{
    get
    {
        return txtText.Text;
    }
    set
    {
        txtText.Text = value;
    }
}

/// <summary>
/// The Value selected by the user using the TrackBar control
/// </summary>
public int SelectedValue
{
    get
    {
        return trackBar1.Value;
    }
    set
    {
        trackBar1.Value = value;
    }
}

/// <summary>
/// The text used as a prompt for user input
/// </summary>
public string InputPrompt
{
    set
    {
        lblInput.Text = value + ":";
    }
    get
    {
        return lblInput.Text;
    }
}

There are 3 points to make about the Client control (or any control you develop):

1. The assembly it resides within must be COM Visible. This is very simply achieved by adding the following line to the AssemblyInfo file of your project:
   
   C#

   [assembly: ComVisible(true)]

2. The project is set to output its binaries to a folder within the WebSite project, see:

   bc.WebClientControls > Properties > Build > Output

   This makes the DLL available to the web site automatically - this is not a necessity, it just makes life a little easier during debugging.

3. The assembly has a pre-build event defined, see:

   bc.WebClientControls > Properties > Build Events > Pre-build event command line

   This command clears the control download cache each time the control is built, so that you always download the latest version. Again, this is not a necessity, it just makes life a little easier during debugging.

2. The ASP.NET Custom Control - bc.WebControls.ObjectTag

This control is implemented as a standard ASP.NET custom control. Of particular note in this implementation are:

1. ObjectActivator.js - This JS is implemented as an Embedded Web resource, and is automatically injected onto the page the control resides on. This file has two purposes:
   1. To work around the IE7 "Object Activation issue"
   2. To hook up values set in the ActiveX control so that they are available on postback
2. ParameterCollectionEditor.cs adds the ability to manage the ActiveX params via a UI in Visual Studio "Design" mode.
3. ObjectTagDesigner.cs adds limited design time support in Visual Studio "Design" mode.
4. ObjectTag.cs: The main control code. Please see inline commenting for more details, but items of note are:
   1. The class implements IPostBackDataHandler in order to examine postback values.
   2. Additional handling is added for the management of parameter view state.
   3. The Render method is completely overridden.
   4. An indexer is added to allow easy access to the parameter values on the server side.
      C#

      public Parameter this[string name] {...}

   5. There is special handling in OnPreRender to check input values, and to register and inject client side support.

3. The ASP.NET WebSite - bc.WebSite

This is just a standard ASP.NET web site, nothing to see here, moving along...

4. The Hosting Page default.aspx

Again, a pretty standard ASP.NET page. However, points of note are:

• The control namespace is registered on the page:
  ASP.NET

  <%@ Register assembly="bc.WebControls" namespace="bc.WebControls" tagprefix="bc" %>

• When in design mode, there is some design-time support for the control.
• Note the addition of a Custom validator, and its syntax. This gives you the ability to check values within the control prior to postback.
• In the code-behind, note the btnSubmit Click event handler - see how parameter values are referenced.
• Also, note the implementation of the OnParameterValuesChanges event.

Running the Solution

That's it for the introduction and background, not to run the site:

• First - build the entire solution (this will make sure the client control gets into the WebSite).
• Next - set the website as the startup project.
• Finally - run the solution.

Note that any (non-write only) values updated in the client control are referenced after submitting the form.

Caveats

The client control relies on the installation of the proper framework on the client side - again, this points to a controlled user base.

There is currently no support for client side events bubbling up to the server - this may be added at a later stage, but currently I'm not aware of any need.

Conclusion

I have presented here a control which simplifies the process of injecting ActiveX controls onto a ASP.NET web page including full postback and validation support while also wrapping functionality to avert the IE7+ "Object Activation" Issue.

It must be stressed again that while this control makes this situation easier - the situation itself is very focused in scope, and relies on a controlled user base.

I look forward to any feedback and suggestions.

History

• Version 1.0 - 17 August, 2009 - Initial release