Developing Custom Controls: Key Concepts

This topic provides a high-level overview of the different programming elements involved in developing an ASP.NET server control. The discussion is intended as a general programming road map; details are given elsewhere in this section. You can author your control in any programming language that is compliant with the Common Language Specification, as described in What is the Common Language Specification?.

An ASP.NET server control is a class that derives directly or indirectly from System.Web.UI.Control. The following two classes are the base classes for ASP.NET server controls.

• System.Web.UI.Control

  The Control class defines the properties, methods, and events common to all ASP.NET server controls. These include methods and events that govern the control execution lifecycle and properties such as ID, UniqueID, Parent, ViewState, and Controls (the collection of child controls). Control does not have any user interface (UI) specific features. If you are authoring a control that does not provide UI, or one that combines other controls that render their own UI, derive from Control.

• System.Web.UI.WebControls.WebControl

  The WebControl class derives from Control and provides additional properties and methods for UI functionality. These properties include ForeColor, BackColor, Font, BorderStyle, Height, and Width. WebControl is the base class for the family of Web server controls in ASP.NET. If your control renders UI, derive from WebControl.

Depending on the functionality of your control, you might have to implement one or more of the following interfaces.

• System.Web.UI.INamingContainer

  INamingContainer is a marker (empty) interface that does not have any methods. When this interface is implemented by a control, the ASP.NET page framework creates a new naming scope under that control. This ensures that child controls have unique IDs in the hierarchical tree of controls. If your control is a composite control (it contains child controls) that provides data binding, if it is a templated control, or if it needs to route events to its child controls, it must implement the INamingContainer interface. Examples are the Repeater control and other data-bound controls. For details, see Developing a Composite Control.

• System.Web.UI.IPostBackDataHandler

  If your control needs to examine postback data and update its state or raise events on the server based on changes to the data, it must implement the IPostBackDataHandler interface. An example is the TextBox control, which examines the posted value of the text and updates its Text property as well as raising a TextChanged event when the text is changed. For details, see Processing Postback Data.

• System.Web.UI.IPostBackEventHandler

  If your control captures a client-side postback event and responds to it by handling it or by raising events on the server, it must implement the IPostBackEventHandler interface. An example is the Button control, which captures a form submission and raises a Click event on the server. For details, see Capturing Postback Events.

You can override properties, methods, and events inherited from a base class as well as add new properties, methods, and events to your custom control. For more information, see Properties in ASP.NET Server Controls, Methods in ASP.NET Server Controls, and Events in ASP.NET Server Controls.

ASP.NET allows controls to access and expose styles, as described in Styles in Server Controls. You can program an ASP.NET server control that allows page developers to customize its user interface through inline templates. For details, see Developing a Templated Control.

To develop a data-bound control that has complex properties that are bound to data, see Developing a Templated Data-Bound Control.

To walk through the steps for creating a simple custom control, see Developing a Simple ASP.NET Server Control.

See Also

Developing a Simple ASP.NET Server Control | ASP.NET Server Controls Hierarchy