Inheriting An ASP.NET Server Control

The following fragment illustrates how the PromptButton class is declared within an .aspx page:

<dc:PromptButton id="WithPrompt" runat="server"
Text="With Prompt" ConfirmMessage="Are you sure?" />

It is important to note that the string after the tag prefix gets combined with the associated namespace to form the fully qualified type name - LaMarvin.Samples.Web.DerivingBuiltinControls.PromptButton in this case.

That's all if you're adding your derived controls through the HTML view of the VS.NET WebForms designer. Funnily enough, when I modified the .aspx page in the HTML view by adding the derived PromptButton controls, the designer generated the corresponding declarations in the .aspx.vb code-behind file only when I've switched to the Design view at least once.

You can also add your derived control to the WebForms designer toolbox so you can create the control's instances using drag & drop from the toolbox. Just right-click the toolbox, choose ' Add/Remove Items...' and browse for the assembly .dll file (it's in the project's bin subdirectory). In order to better support the design-time experience, you might want to customize the initial HTML code that is generated by the designer when you place a new instance of your control onto a form.

You can do this by applying the System.Web.UI.ToolboxDataAttribute attribute to your derived control class:

<ToolboxData("<{0}:PromptButton runat=""server"" ConfirmMessage=""Hello!"" />")> _
Public Class PromptButton
Inherits System.Web.UI.WebControls.Button

Note that you must always include the string "{0}", which gets replaced be the actual tag prefix used within the page. Also you have to include the runat = "server" attribute, otherwise the designer won't be able to instantiate your control.

Beware, however, that when you change the ToolboxDataAttribute for a control that you've already put onto the toolbox, you'll have to remove it and re-add it again (recompile doesn't suffice). I don't know the reason for this. It seems that the designer is caching the attribute's value somewhere when the control is added to the toolbox.

Despite this small annoyance, deriving from an ASP.NET server control might be useful technique if you need functionality that "is-a" extension of an existing server control.