Enhancing 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 allows developers to 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.

The design-time support for components in the .NET Framework, however, is not defined exclusively by a design tool such as Microsoft Visual Studio .NET. Rather, 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 .NET 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.

While many of the design-time systems discussed in this section apply to components in general, 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, which is rendered by the client's browser or other viewing device. A Windows Forms control, on the other hand, typically does its painting using GDI+ (the new Windows graphics library).

In This Section

  • Design-Time Architecture
    Provides an overview of design-time architecture in the .NET Framework.
  • Attributes and Design-Time Support
    Describes how to use custom attributes to associate design-time support with a particular component or control.
  • Generalized Type Conversion
    Describes methods for translating values between types.
  • Implementing a Type Converter
    Describes how to implement a type converter to translate values between data types, generate property initialization code at design time and supply a list of standard values to the property grid for a supported data type.
  • Implementing a UI Type Editor
    Describes how to implement a UI type editor that allows visual value configuration for a custom type.
  • Implementing an Extender Provider
    Describes how to implement an extender provider that allows properties to be added to a component at design time or at run time.
  • Custom Designers
    Describes the key concepts behind implementing a designer (a class that can govern the visual representation and behavior of a component at design time).
  • Design-Time Support for Web Forms
    Describes details relevant to implementing design-time support for Web Forms and provides samples of Web Forms designers.
  • Design-Time Support for Windows Forms
    Provides samples of design-time implementations in Windows Forms, such as UI type editors, extender providers, and designers.