ASP.Net UserControl Life Cycle in DesignMode

February 24, 2011

The ASP.Net Page Life Cycle is described on a couple of blogs such as this detailed description (including achart and code). The description, however, usually deals with the life cycle during runtime.

But what about the design time behavior of compiled user controls?

I took the code from Justin’s Blog (first link) to trace the events triggered in DesignMode, and, after a bit of adjustment, found the following DesignMode life cycle:

Open a page containing the compiled ascx in Visual Studio designer

  • Construct
  • public property setters (for properties set in the ascx)
  • ResolveAdapter
  • OnInit
  • TrackViewState
  • CreateControlCollection

Navigate to the control in designer

  • all public property getters
  • public property setter (as you edit a property value in designer)

Close the page in designer

  • OnUnload

Wiring Events of ASCX Controls after ParseControl

February 24, 2011

After you loaded your control definition from the ascx and retrieved the embedded controls using FindControl(), you notice that the child controls’ events do not fire anymore.

While the Page_Load and other Page_ events fire correctly for the control that loaded the ascx, the events for the controls inside the ascx are ignored: You need to wire them explicitly in code.

If, for example, your ascx contains a button declaration

<asp:Button ID="btnCalc" runat="server" OnClick="btnCalc_Click"  />

you need to retrieve the control and wire the event like this

btnCalc = (Button)this.FindControl("btnCalc");
btnCalc.Click += btnCalc_Click;

Simplest Logger for .Net?

February 23, 2011

If you need to supply logging functionality for your application, you most likely use well known logging frameworks such as log4net or the Logging Application Block from Microsoft’s Enterprise Library.

But logging frameworks may be overkill if you just need to trace a couple of output lines while debugging on your development machine, and a simple procedure might be sufficient:

void Log(string s)
    DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss") + " " +
    s + "\r\n");

Whether you implement this procedure as private or as (static) public is up to your use case.

A little extension even supports indentation:

int indent = 0;
void Indent() { indent += 2; }
void Unindent() { indent -= 2; }

void Log(string s)
    DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss") + " " +
    new string(' ', indent) +
    s + "\r\n");

void StartLog(string s)
  Log("Start:" + s);

void EndLog(string s)
  Log("End:" + s);


Handling tilde (~) paths in ASCX correctly using ParseControl

February 22, 2011

Using ParseControl to load ASCX files stored as EmbeddedResource, I found that tilde paths (“~” denoting app root) were not interpreted to mean application root, but were left unchanged in markup attributes.

The solution is to set the AppRelativeTemplateSourceDirectory member variable of the loading control:

Control userControl = page.ParseControl(content);
this.AppRelativeTemplateSourceDirectory =

Cross-Browser Check for ActiveX in JavaScript

February 15, 2011

Once you created an ActiveX control, you need to embed it in your web page.

This is typically done by creating a new ActiveXObject(“myActiveX”), an object type which is only available in Internet Explorer.

To find out whether this object type is implemented, I try to create it, and check the exception name: Firefox has “ReferenceError”, whereas IE returns “Error”. This information is stored in the variable isActiveXCapable.

Next, we create the ActiveX using its registered class name.

Depending on whether the object can be created and, if not, on the result of the first test, we can distinguish the 3 cases:

  • Browser does not support ActiveX
  • Browser supports ActiveX, but the requested class is not installed
  • Browser supports ActiveX, and an object has been created
<script type="text/javascript">
var myActiveX = null;
var isActiveXCapable = false;

function InitMyActiveX() {
  try {
    new ActiveXObject("");
  catch (e) {
    // FF has ReferenceError here
    if ( == 'TypeError' || == 'Error') {
      isActiveXCapable = true;
  try {
    myActiveX = new ActiveXObject("My.ActiveX");
  catch (e) {
    myActiveX = null;

  if (myActiveX != null) {
    document.getElementById("myInfo").innerHTML = myActiveX.GetSomeInfo();
  } else {
    document.getElementById("CallMyActiveX").setAttribute("disabled", "disabled");

    if (!isActiveXCapable) {
      document.getElementById("myInfo").innerHTML = "Browser does not support ActiveX";
    } else {
      document.getElementById("myInfo").innerHTML = "MyActiveX is not installed";

function DoSomething() {
  if (myActiveX != null) {
    var s = myActiveX.DoSomething();
    document.getElementById("myResult").innerHTML = s;

<div id="myInfo"></div>
<input type="button" id="CallMyActiveX" value="Call me" onclick="DoSomething()"  />
<div id="myResult"></div>

Implementing Safe-for-Scripting ActiveX in C#

February 15, 2011

If you want to create an ActiveX control which is marked as “safe for scripting” to be used in Internet Explorer, you need your control to implement the IObjectSafety interface.

Luckily I found this blog describing a default implementation of IObjectSafety

For a step-by-step description on how to create an ActiveX with IObjectSafety and correspondig installer project (.msi) including screenshots, see this blog.

That said, apart from the requirement that the developer needs to implement this interface, nothing is going to prevent that the ActiveX does real harm once installed.

Worse, the ActiveX is instantiated to be queried whether it is a “good” control, opening the door for malicious code.

See the security discussion in this mail list archive.

DevExpress ASPxGridLookup forgets Value if Active Tab changes in ASPxPageControl

February 13, 2011

I have an ASP.Net web form with an ASPxPageControl with one TabPage containing an ASPxGridLookup control.

I noticed that as the active tab changes by setting ActiveTabIndex or ActiveTabPage during post-back, the ASPxGridLookup control forgets its selected values and clears the .Text and .Value properties (empty string and null, respectively).

My work-around was to store the value of the page control’s .Text property in either a TextBox control set to Visible=false, or in a HiddenField, and retrieve this value in Page_Load() if IsPostBack==true. (Another possibility would be a ViewState key/value pair).

A similar bug has been reported on, and acknowledged by devexpress.