CreateChildControls
		Home « Computers « DevBlog

Back to: Development Blog Contents

A trap for ASP.NET Developers using Child Controls

Introduction

In November 2003 I started writing a single-page ASP.NET application to help the Australian Skeptics committee members read the incoming email. Each evening a utility program extracted unread emails from a designated Outlook mail folder and dumped them into a database table so committee members could browse them using ASP.NET application.

I write this blog section to explain that I feel for a silly trap and endured many hours of suffering because I did not carefully obey the rules of creating and working with System.Web.UI.Control derived Server Controls in an ASP.NET page. I hope that I can save other programmers from wasting time on the same problem.

The "Non-Event" Symptoms

My page uses nested child Server Controls which are actually Composite Controls, each one having a set of various types of controls added to its Controls collection. The nested child controls all render themselves, so it's a very neat way of building a complex web page.

In the first draft of the application I was (foolishly) creating the child controls in the constuctors and then setting the values and attributes of the children in the CreateChildControls method. Everything rendered correctly, but no child control events fired. I would click a child Button and a postback would occur, but the Click event would not run. I was utterly puzzled for hours because I seemed to be doing everything correctly and page looked perfect. I just had no events firing from the dynamically created child controls.

The Solution (Part-1)

I eventually realised that I had partly forgotten these important facts to solve my problem:

• You must create the child controls and set and set their IDs in the CreateChildControls event...nowhere else. Otherwise, the framework does not seem to know the IDs of the controls at the time of wiring-up the events.
• Your Server Controls must derive from the INamingContainer interface. Without this, you may get ambigious control IDs.

The first point was the crucial one. The CreateChildControls event is a very precious and delicate one, and you must create your child controls there and assign them unique IDs. I was previously creating the controls in the constructor, and this was my fatal mistake, even though I was assigning IDs and other properties later in CreateChildControls.

I can't believe I had fallen for such a stupid trap, as only a couple of months earlier I had been writing nothing but ASP.NET for 4 months and I would surely have remembered the fine print of creating controls. After several weeks of writing nothing but Forms apps I had forgotten many ASP.NET traps.

Further "Timing" Problems

I ran into a further problem that was purely personal, as the CreateChildControls method was sometimes being invoked by the framework before I knew what values and attributes to apply to the controls. The CreateChildControls method can be called at very unpredictable times in the postback life-cycle of a web page. For example when clicking a child button, its CreateChildControls method was called before the parent page had even run Page_Load.

In some cases I had no idea what values to put in the child controls until long after they were created. A button click event could change the control contents after they had been created. I seemed to be in a catch-22 where I had to create the controls before I knew what to put in them.

The solution is well documented, but once again it's easy to forget and it's a delicate thing to code. You need to do this in the parent when the contents of the already-created children will change:

ChildControlsCreated = false

This magically causes the CreateChildControls method to trigger and run again and you can set the children correctly before they are rendered.

Back to: Development Blog Contents