If you take a control's functionality and content and add to them the other means necessary for a container to manipulate a control, you'll come up with five mechanisms that all controls must provide:
On the other side of the picture, a control container must provide various services to all controls within its form or document. Each control in the container is given its own control site, just as a content object is given a site in a compound document. These sites expose to the control container properties called ambient properties because they define the ambiance of the control's environment. By using ambient properties, the container can specify the default colors, fonts, alignment, and behavioral suggestions. Controls can choose to retrieve these properties from the container at run time to integrate themselves better into the form or document as a whole.
A container must also supply a control with event handlers—container-provided implementations of a control's outgoing interfaces that we can also refer to as event sinks. The container determines what other actions should be executed when the various functions in these event interfaces are called.
Besides dealing with properties and events, the container must also provide all the other facilities for object layout, ordering, and keyboard processing because only the container is aware of all the objects in a form and the relationships between those objects. It must also facilitate saving the document or form to a file for later reloading. If appropriate, the container can provide additional user interface features for the registration and creation of controls (for example, a dialog to add controls to the registry and a toolbar populated with buttons that represent the registered controls).
With these items in mind, we can draw up a list of the required mechanisms for a control container:
In general, a container will also support different operational modes, named design mode and run mode. In design mode, the container is oriented toward assigning actions to control events, creating new controls, moving controls around in a form, and performing other tasks concerned with the form's design. A container can deactivate all controls at this time or simply tell controls to ignore user input. In run mode, also called user mode, the controls on the form are fixed in number and in position and any events a user sends trigger the actions assigned to those events in design mode. The container tells controls how to behave in each mode through ambient properties, as we'll see shortly.