What’s on the page?
Let’s start with what you add to the ASP.NET page. These are the components that would be responsible for generating the appropriate JavaScript code, etc.
Let’s say, you added an AutoCompleteExtender to the page. You would do the following:
Figure 1: The basic extender related controls on a page

- Make sure a ScriptManager is there on the page (either on the page itself or from a Master Page)
- Add a textbox (e.g. txtSearch whose runtime ID becomes something like ctl00_txtSearch). Since this is an extender control, this text box is called the Target Control.
- Add an AutoCompleteExtender with the appropriate properties and link it to the above textbox. This is the actual custom control that uses the functionality provided by the MS AJAX libraries.
What happens on the server-side?
The MS AJAX custom controls have both a server-side piece and a client-side. The server-side piece is written in the .Net languages (the main libraries are in C#); and the client-side piece is JavaScript code (small blocks are generated in addition to the .js files from the libraries)
First let’s take a look at what gets generated by the server side.
The Classes on the Server-side
Figure 2: The server-side class hierarchy

AutoCompleteExtender class is the primary class for the auto complete functionality. This class is derived from ExtenderControlBase.
ExtenderControlBase is derived from ExtenderControl class. This is the base class for the controls in AJAX Control Toolkit.
ExtenderControl is derived from the Control class. This class is from ASP.NET 2.0 AJAX Extensions or the MS AJAX; it forms the base class for all the extender controls eventually. The ExtenderControl resides System.Web.UI namespace.
And finally, needless to say, the Control class from ASP.NET is the base class for all the custom controls.
The Flow
Since these classes are derived from Control class, they override the Render method. When the asp.net framework tries to render an instance of the auto complete extender control you placed on the page, it calls these render methods. The call flow is like this:
Figure 3: The flow of render methods

Following are the various components involved in rendering an Extender Control:
- ASP.NET Framework
- Render from AutoCompleteExtender (this class has no Render, so, the base Render is called)
- Render from ExtenderControlBase
- Render from ExtenderControl
- RegisterScriptDescriptors from ScriptManager
- The Render method from ExtenderControl calls the RegisterScriptDescriptors method.
The Generated script
Based on the properties you set for the extender control, an initialization JS script is generated. This script, as seen below is placed on the page and gets executed by the browser on the client-side.
In summary, ScriptManager (along with other components) generates the initial component management/initialization code:
<script type="text/javascript">
<!--
Sys.Application.initialize();
Sys.Application.add_init(function() {
$create(AjaxControlToolkit.AutoCompleteBehavior, {"id":"ctl00_aceSearch","minimumPrefixLength":1,"serviceMethod":"GetTagList","servicePath":"SearchTags.asmx"}, null, null, $get("ctl00_txtSearch"));
});
// -->
</script>
If you see the add_init method above, you see a whole bunch of properties from the auto complete extender. How does the ScriptManager know to generate these properties and the associated values? It simply calls the control (the auto complete extender) itself. The ExtenderControlBase class implements IExtenderControl interface (via the ExtenderControl). This interface has a method called GetScriptDescriptors. The control furnishes the information about what script to render.
Client Side Activity for initialization
From the above discussion, we know that the server side has generated the following JS script and placed it on the page.
Sys.Application.add_init(function() {
$create(AjaxControlToolkit.AutoCompleteBehavior, {"id":"ctl00_aceSearch","minimumPrefixLength":1,"serviceMethod":"GetTagList","servicePath":"../SearchTags.asmx"}, null, null, $get("ctl00_txtSearch"));
}
The add_init method in the Sys.Application class can be used to register an event that gets raised after all the scripts have been loaded. As the page loading process progresses, other scripts and js files that belong to MS AJAX and the AJAX Control Toolkit will become available to the browser.
So, after all the scripts have been loaded, the following function gets called (this is the function that’s gotten registered above as the event handler):
function()
{
$create(AjaxControlToolkit.AutoCompleteBehavior, {"id":"ctl00_aceSearch","minimumPrefixLength":1,"serviceMethod":"GetTagList","servicePath":"../SearchTags.asmx"}, null, null, $get("ctl00_txtSearch"));
}
In essence, this event gets added to the EventHandlerList (as in Sys.EventHandlerList). At the core of this EventHandlerList is an array variable that holds the event details.
Creating the Component on the client side
$create is a shortcut for Sys.Component.Create method. The Sys.Component is the client-side for the controls that are to be managed by ASP.NET. The create method that is part of this class initializes a component.
As you can see, the $create takes five parameters:
Type (the type of component to create):
AjaxControlToolkit.AutoCompleteBehavior
Properties (in JSON format):
{“id”:”ctl00_aceSearch”,”minimumPrefixLength”:1,”serviceMethod”:”GetTagList”,”servicePath”:”../SearchTags.asmx”}
Events and Event Handlers:
null
References (to other components):
null
The DOM element to which this component is attached to:
$get(“ctl00_txtSearch”). This is the textbox to which the autocompleteextender is associated to (another shortcut $get is used to get the ID of the textbox)
With this there is information about this instance of auto complete extender on both the client and the server. Depending on the implemented features, they will be able to talk to each other seamlessly.
Additional Related Articles
Using AutoCompleteExtender with results from database
The structure and usage of AutoCompleteExtender control