Partager via


Extending Design-Time Support

The .NET Framework provides an extensible architecture for customizing the behavior and display of components and controls in design mode. This design-time support architecture lets developers build customized design-time extensions for components and controls. Developers can provide custom design-time behavior, value configuration interfaces, code generation for property initialization, and take advantage of services provided by the design-time environment.

For example, if you define a property of a custom type on a control, you can provide a custom user interface, or type editor, to edit the value of that property using a property browser. You can build a class called a designer that can manage a variety of aspects of a component or control's appearance and behavior at design time.

In the past, support for special case logic for components in design mode was built into the form designer, and it was the form designer, not the object, that was responsible for providing design-time capabilities. In the ActiveX world, for example, different tools offered their own form designers, with different user interfaces and capabilities. Because a product's fixed feature set cannot account for the needs of all controls, ActiveX controls had only a limited level of custom design-time support.

However, design-time support for components in the .NET Framework, is not defined exclusively by a design tool such as Visual Studio. Instead, the development environment supports the extension and definition of design-time behavior by classes such as designers that provide design-time support for components. Support for extensible and customizable design mode behavior is an integrated part of the .NET Framework. Tools such as Visual Studio also provide a range of design-time services that designers can use.

This section provides background information and samples to help component and control developers add design-time functionality to components.

Although many of the design-time systems discussed in this section apply to components generally, some are specific to Web Forms or to Windows Forms. There are design-time differences between ASP.NET Web Forms and Windows Forms because the mechanism of rendering ASP.NET server controls is different from that of rendering Windows Forms controls. An ASP.NET server control sends HTML or another markup language to a client. This language is rendered by the client's browser or other viewing device. A Windows Forms control, on the other hand, typically paints by using GDI+, which is the new Windows graphics library.

In This Section