| Custom controls are compiled controls that function a lot like ASP controls. Like user controls, custom controls can significantly enhance the reusability of code that is repeated many times within a project or over multiple projects. There are important differences, however. In general, user controls are like "mini" web pages in that they contain part of an ASP.NET page. Additionally, they are compiled when first requested , but their user interface can easily be changed as required. With custom controls, on the other hand, the user interface is generated by the code and therefore cannot easily be changed, except through properties and methods that you implement, about which we'll speak more in a minute. In a broader sense, a custom control is really any control that you create with these common themes: it is typically derived from the Control (or WebControl ) class in the System.Web.UI namespace or an existing ASP.NET server control; it generally provides its own user interface; and it may provide its own backend functionality through the methods, properties, and events that you implement for it. Custom controls range from the simple to the complex. A simple custom control might, for example, write some HTML, perhaps even modifying its HTML-style attributes as it does so. A more complex custom control would offer HTML-style attributes of its own through properties you implement. A custom text box control could, for example, offer one attribute for controlling the color of its label and another to control the width of the control itself. To make it more complex, and ultimately more useful, the control would have to handle postback events like the server controls provided with ASP.NET. More complex still would be a custom control that, like the DataGrid control, included templates and supported data binding. Because custom controls can be created from scratch or inherited from existing controls, the possibilities are endless. All of the hypothetical custom controls we've just described are, with the exception of the templated control, illustrated in this chapter's recipes. (If you're interested in learning more about templated controls, see the example in the ASP.NET QuickStart Tutorials that are part of the .NET Framework QuickStarts that ship with Visual Studio .NET or are available via http://www.gotdotnet.net.) This chapter introduces you to some, but not all, of the techniques used to build custom controls. In sticking to the basics, we are implicitly recognizing that custom controls are, after all, "custom" and therefore highly individual. But these basics ought to take you a long way in crafting your own custom controls. Which Is Better: WebControl or Control? On the subject of creating custom controls, some books, including several from O'Reilly, recommend inheriting from the WebControl class as opposed to the Control class of System.Web.UI , which we have used for the majority of recipes in this chapter. Using WebControl is certainly a good option, because it serves as the base class that defines the methods, properties, and events common to all web server controls in the System.Web.UI.WebControls namespace. Using this approach, you can control the appearance and behavior of a web server control by setting properties defined in this class ”for example, the background color and font color of a control or the border width, color, and style of a control. But to really "get under the hood" in creating a custom control's UI, the class to inherit from is Control , because it makes available the largest number of options. The cost of this increased flexibility is that it requires a bit more planning and execution. The reason is that Control does not have any user interface-specific features. If you are authoring a control that does not have a UI, or combines other controls that render their own UI, derive from Control . Otherwise, if you are authoring a control that can make use of the properties and methods provided by WebControl , derive from WebControl . |
|
