If the suite of built-in ASP.NET server controls does not have a control with the characteristics you need, you can roll your own by deriving from Control or WebControl. In this way, you are responsible for implementing the programming interface and behavioral logic of the new control. You can even modify existing web controls by deriving classes of your own from them. In this case, the new control already has a well-defined behavior, and your task is to customize it to your desired extent.
Overall, it is worth noting that ASP.NET controls are limited in their functionality by the HTML language and HTML object model of the browser. When you need a certain functionality that no existing control provides, the first thing you should ask is whether that functionality can really be obtained from an HTML environment altogether and what support it expects from the browser. ASP.NET is primarily an abstraction layer built on top of HTTP and HTML, so its controls can’t reach functions that can’t be expressed with HTML elements and script code.
A control is made up of two key blocks of code—the programming interface and the rendering logic. The programming interface is the set of properties, methods, and events that let users and visual designer tools (i.e., Visual Studio .NET) interact with the control. dotnetfx.exe /C:"install /noaspupgrade"
By inheriting a base class—be it Control, WebControl, or another more specific control—you bring into the new class a well-defined set of members. You can add new ones or override some of them. As ab alternative to overriding a member, you can choose to replace the member of the base class with a new one having the same name and type. This normally happens when you want to restrict or enlarge the visibility of the member. For example, consider exposing a read/write property as read-only. To shadow a base property in C#, you use the “new” keyword instead of “override.” In Visual Basic .NET, you use “Shadows” in lieu of “Overrides.”
The rendering logic is the code that provides the HTML markup to be sent to the browser. You normally need to write this code from the ground up only if you’re building a control from either Control or WebControl. This need is significantly less frequent if you inherit your component from an existing, non-base control. For web controls, the entry point in the rendering process is the RenderControl method. The method is declared public in the Control class and inherited by all ASP.NET controls. The method outputs the content of the control to a provided HtmlTextWriter object and, if tracing is enabled, stores tracing information about the control.
The ASP.NET rendering mechanism, though, is extremely layered and involves several methods at various levels. The base behavior of the RenderControl method entails that a call is made into a protected, overridable method named Render. In the base implementation that provides the Control class, the Render method calls into another protected member named RenderChildren. As the name suggests, RenderChildren loops over the contents of the control’s Controls collection and polymorphically calls the RenderControl method on any child controls.
The WebControl class, which is a first-level child of Control, overrides RenderControl and implements it in three steps that recalls the structure of the final HTML output—begin tag, contents, and end tag. As a result, if you want to modify the output of a control, you should look at RenderContents and override it. Unlike RenderContents, which is protected, RenderBeginTag and RenderEndTag are declared public. They render the opening and the ending tag of the HTML text for the control, and as such they are much less subject to overriding than RenderContents.
When it comes to writing a new control from scratch, should you inherit from Control or WebControl? WebControl in turn inherits from Control and extends it with a fixed number of members related to the user interface (i.e., font and color properties). In many cases, WebControl is just fine, but look into its base members before you choose.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
