First Article – The Basics of Building Server Controls
Second Article – Reusing and Creating Server Controls (Previous article)

Download the source code demonstrated in this article.

Ever wanted to merge two controls together to form one control? The need may arise in the future that you will have to pull multiple controls together to form one, unified server control. These “unified” server controls are given a name – called composite server controls.

Composite server controls are a collection controls to create one unified control; however, do not confuse this term that two control's functionality and behaviour are being combined/merged under one server control. Instead, rather think that composite controls as multiple controls are working together, for each other – to create more complex functionality. But what criterion must be met before a control is declared composite? It must be able to:

• Contain other server controls as children – no matter how those server controls get there (you will see the different ways on how the children controls are added to the server controls in this article).

• Hook up the children controls so they provide some unique functionality. In example: a TextBox control, a Button control and a Repeater control in a user control to provide some type of search functionality. The TextBox control will contain the search query and the Button control will fire a Click event to indicate the search must begin. Then, the search results will then be relayed in the Repeater control via data binding.

To give a few examples of composite controls, take a look at the DataGrid control, user controls and the ASP.NET page. The file based controls (the user control and ASP.NET page) are composite controls because they can hold an abundance of controls to create an user interface. They also hook up each others event to provide some type of functionality or meaning to the control – that is what a composite control is about: hooking up loose functionality from other controls.

The DataGrid is a composite control because it adds other controls inside itself when it is data bounded to a data source. The DataGrid also has the ability to create functionality of the controls it can add. For example, if a DataGrid's content can be edited (enabled by the page developer), the DataGrid uses a Button control (lets call it the edit button) to listen for the edit button's Click event. When the DataGrid hears the edit button click event, it will then issue an Ok/Cancel buttons (also Button controls) and the DataGrid will then listen to those buttons for further notifications. On top of the Ok/Cancel buttons being issued, the columns are converted to editable regions such as text boxes (this is default behaviour although this can be changed).

When the DataGrid hears that the Cancel button was clicked, then the DataGrid exits out of edit mode. If the DataGrid hears that the Ok button was clicked, it would then raise an event to detect that a row has been “edited” by the user. The event will change the DataGrid's internal DataSet (which is, by default, saved to view state to be re-used for every post back for that page). Furthermore, it will alert the code watching over the DataGrid that there has been changes (from the user) and it is up to the listeners to make any additional changes – normally, to a database.