Creating Custom Controls in Visual Studio NET

Most developers creating custom controls and other .NET projects won't use Windows Notepad to create their projects. It's certainly possible to do so , but given the size of the common language runtime, features like IntelliSense and statement completion make using the Visual Studio .NET development environment very handy.

The only downside of using Visual Studio .NET is that it contains some generated code that the developers of the project skeletons thought was important that might not be important to you. For example, if you create a new Web Control Library project in Visual Studio .NET, the generated code will look like the following (reformatted for clarity):

Imports System.ComponentModel

Imports System.Web.UI


ToolboxData("<{0}:WebCustomControl1 runat=server>

Public Class WebCustomControl1

Inherits System.Web.UI.WebControls.WebControl

Dim _text As String

<Bindable(True), Category("Appearance"), DefaultValue("")> Property [Text]() As String Get

Return _text End Get

Set(ByVal Value As String)

_text = Value End Set End Property

Protected Overrides Sub Render( _ ByVal output As System.Web.UI.HtmlTextWriter) output.Write([Text]) End Sub

End Class

In addition to some default names that obviously should be changed (such as the default class name, WebCustomControll), you'll likely need to make other changes as well. First, Visual Studio generates a class that inherits from

System.Web.UI.WebControls.WebControl. In many cases, this will be what you want to do, but in others, you'll want to inherit from a different class, as we did earlier with the CenteredLabel control. Next, there's the Text property and the _text data element within the class. In many cases, you might want to retain this property and the supporting data element, but just as often you won't. One thing to note here is the relationship between the name of the property and the name of the data element. The property is Pascal cased, and in the case of Visual Basic .NET (a case-insensitive language), the actual class data element is preceded by an underscore. In a C# Web Control Library project, the property name would remain the same, but the class data member would simply be text, because C# is case-sensitive.

There are attributes for both classes and namespaces. The first, in this case not created by default when you create a custom control using Visual Studio .NET, is the TagPrefix attribute. If you don't specify a TagPrefix attribute, Visual Studio .NET will generate a tag prefix for you, so your custom controls, when dragged onto the form, will begin with cc1, continuing with cc2 for the next control, and so on. Using a TagPrefix attribute allows Visual Studio .NET to use a more convenient name for the tag prefix. For example, the following code specifies that the tag prefix for the RequiredTextBox class is MyControls:

[ assembly:TagPrefix("MyControls","RequiredTextBox") ]

This is the C# syntax. The Visual Basic .NET syntax is similar, but with angle brackets (<>) enclosing the attribute.

At the class level, there's another important attribute: ToolboxData, which is provided by Visual Studio .NET. An example of this attribute using the Visual Basic .NET syntax is shown here:

<ToolboxData("<{0}:WebCustomControl1 runat=server> </{0}:WebCustomControl1>")>

Visual Studio .NET will provide a default tag when a control is dropped on a form; however, the ToolboxData attribute allows you to specify additional attributes that will be set whenever you drag a control on a form. In this example, the runat=server attribute/value pair appears by default whenever the control defined by the class is dropped on the form. After you've experienced the failure of your custom control, only to discover that you forgot to add the runat=server attribute/value pair, you'll really appreciate having all custom server controls dropped on the form complete with runat=server.

The attributes used for properties by the Visual Studio .NET design-time environment are shown in Table 6-2.

Table 6-2 : Attributes Available for Controlling the Design-Time Environment for a Custom Control Property




Specifies whether a property should be displayed in the

DataBinding s dialog box


If the property grid is sorted by category, specifies the category the property should be in


Specifies the default value in the designer


Specifies how (or whether) changes made to the property should be persisted

Brows able

Specifies whether a property is displayed in the designer


Specifies the type converter to use for converting the property type to another type


Hooks up the extended user interface for setting the property

0 0

Post a comment