Design-Time Components

Before components, controls, and user controls can start using design-time features, they must integrate with the design time itself. As discussed in Chapter 9: Components, the point of integration between a class and the design time is modeled by the IComponent interface:

namespace System.ComponentModel {   interface IComponent : IDisposable {      ISite Site { get; set; }    event EventHandler Disposed;   } }

IComponent is the fundamental building block of the entire design-time infrastructure, on which all the design-time features we discuss in this book depend. Consequently, your custom components, controls, and user controls must implement IComponent.

In Chapter 9: Components, we looked at a custom IComponent implementation, although we found we could save the effort in most cases by deriving from .NET's base IComponent implementation, System.ComponentModel.Component. In both Chapter 9 and Chapter 10: Controls, you saw that all .NET Framework and custom components and controls implicitly implement IComponent as long as they derive from Component, Control, or UserControl, as shown in Figure 11.1.

Figure 11.1. Types That Directly or Indirectly Implement IComponent

Figure 11.1 also shows that neither UserControl nor Form directly inherits from Control. Instead, they both derive from ContainerControl, itself deriving from ScrollableControl, both of which overlay Control with control containment and scrolling support commonly required by user control containers, including user controls and forms. Both ScrollableControl and ContainerControl are base classes for implementations that require specific types of support, but you'll find that your classes typically derive from Component, Control, or UserControl.

No matter how a class comes to implement IComponent, it is known as a design-time component if it does.^[1]

^[1] For the sake of readability, design-time components are simply referred to as "components" for the remainder of this chapter.