Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Creating a Data-Bound Web Parts Control

By inheriting from the WebPart base class, you can give Web Parts capabilities to an ordinary data-bound server control. In Web Parts applications, end users are able to modify (personalize) the behavior and user interface (UI) of server controls, and have their settings saved in long-term storage for future browser sessions. Users can drastically change the look and feel of a page by adding or removing controls, editing the properties and appearance of controls, rearranging the page layout, importing or exporting settings for the controls, and even forming connections that enable controls to share data. To learn more about Web Parts applications, see the topics listed in ASP.NET Web Parts Controls. This topic describes the prerequisites for using a custom, data-bound WebPart control (or any server control) in a Web Parts application, and summarizes some members of the base WebPart class that are often useful to implement or override when creating a custom control. An example of overriding and implementing some of these members is provided in the topic Data-bound Web Parts Control Example.

No Web Parts control can run in isolation and still retain its Web Parts features. If you run a WebPart control in a Web application without the other required elements for a Web Parts application, the control simply loses its Web Parts features and functions as an ordinary server control. The following list explains the required elements that must be in place before you can use a custom WebPart control with Web Parts features:

Although any type of server control can be used in Web Parts applications, there are some benefits to creating custom WebPart controls (for details, see Using ASP.NET Server Controls in Web Parts Applications). When you inherit from the WebPart base class, there are no required members to implement. There are, however, some commonly used members that you might want to use or override, and these are summarized in the following table. For a complete example of a data-bound server control implemented as a WebPart control, see Data-bound Web Parts Control Example. The following table summarizes some of the commonly used members.




A common usage for this constructor is to set default values on some of the properties that determine the appearance and behavior of a WebPart control, like the properties inherited from the Part class, or behavioral properties such as the AllowEdit and AllowLayoutChange properties.

Behavioral properties

This includes a number of the "Allow" properties of the class, such as AllowClose, AllowConnect, AllowEdit, AllowMinimize, AllowLayoutChange, and AllowZoneChange. Rather than simply assign default values to these properties in the constructor, developers can completely control a property, for example by preventing users or developers who use the control from ever being able to close the control.


When you inherit from the WebPart class, you need to provide a UI for your custom control. A very effective way of doing this is to override the CreateChildControls method and, in this method, add other server controls to make up the UI of your custom control. You might need to carry out additional tasks when you add these controls, such as creating custom event handlers for them, or binding them to a data source.

Rendering methods

You might need to override common rendering methods such as RenderControl or RenderContents. In these methods, you can either completely override the rendering, or call the base method first, and then modify some aspect of the rendering.


If you create custom WebPartVerb objects that will appear on the verbs menu of your control with the standard verbs (such as close and minimize), you must add them to the Verbs collection of your control.


If you create custom EditorPart controls, to enable users to edit the custom properties on your control, you must associate them with your control by overriding the CreateEditorParts method. For an example, see the IWebEditable interface.


When you create custom properties in your WebPart control, you will often want users to be able to edit and personalize those properties, just like the standard WebPart control properties, so that their settings can be saved. Add the Personalizable metadata attribute to any property that users should be able to personalize.

For a full code example that demonstrates how to create a GridView control that binds to the Northwind database, and implements the control as a WebPart control, see Data-bound Web Parts Control Example.

© 2015 Microsoft