Programming Microsoft ASP.NET 4 - Dino Esposito [270]
Control vs. WebControl
The Control class defines the properties, methods, and events common to all ASP.NET server controls. These include the methods and events that determine and govern the life cycle of the control, plus a few properties such as ID, UniqueID, Parent, and ViewState and the collection of child controls named Controls.
The WebControl class derives from Control and adds extra properties and methods, mostly regarding control styles that affect rendering. These properties include ForeColor, BackColor, Font, Height, and Width. WebControl, in particular, is the base class for the family of Web server controls in ASP.NET.
When developing a new ASP.NET control, there’s just one guideline to follow. If your control renders a user interface, you should derive it from WebControl. If you’re authoring a component that doesn’t provide specific user-interface features, you’re better off using Control as your base class. Although these rules are effective in most cases, there might be exceptional situations in which you would reasonably do otherwise. For example, you can derive from Control if you want to provide a subset of the user-interface features.
When building composite controls—that is, controls designed by aggregating multiple controls together—you might want to use CompositeControl as the base class. You should never use UserControl, on the other hand, as a base class for a custom control.
Related Interfaces
Depending on the functionality of your control, you might have to implement additional interfaces. Typically, a server control implements some of the following interfaces:
INamingContainer This interface, also referred to as a marker interface, doesn’t contain methods—it simply notifies the ASP.NET runtime that the control that exposes it should be treated as a naming container. Child controls contained within a naming container control have their UniqueID property prefixed with the ID of the container. The naming container, therefore, acts as a namespace and guarantees the uniqueness of the control’s client IDs within the specified naming scope. (Note that if the ClientIDMode property is set to Static, this warranty just ceases.) The use of the INamingContainer interface is essential if you’re writing composite controls or controls that include templates.
IPostBackDataHandler The interface is needed whenever your control has to examine postback data. If the user can execute actions that affect the state of the control, you need to look into the postback data. For example, a TextBox control stores its configuration in the view state but also needs to read what the user typed in through the browser. This scenario is just where the IPostBackDataHandler interface fits in. The method LoadPostData lets controls examine posted values. The interface is also helpful if you need to raise events on the server based on changes to the data (method RaisePostDataChanged). Again, the TextBox is the perfect sample control; if the data changed between postbacks, the TextChanged event is also raised.
IPostBackEventHandler The interface serves to capture a client-side postback event (for example, a click). Upon postback, after raising data change events, the ASP.NET runtime looks for a server control whose UniqueID property matches the name of a posted value (for example, the name of the clicked button). If a match is found and the control implements IPostBackEventHandler, ASP.NET invokes the RaisePostBackEvent method on the control. RaisePostBackEvent is the only method defined on the IPostBackEventHandler interface. What a particular control does within the RaisePostBackEvent method can vary quite a bit. The Button control—a simple control that implements this interface—fires its Click event when ASP.NET invokes the RaisePostBackEvent method.
Choosing a Rendering Style
For an ASP.NET server control, the sole purpose in life is outputting markup text. The control’s object model and the