Provides the base implementation for the INestedContainer interface, which enables containers to have an owning component.
Assembly: System (in System.dll)
Creates a site for the component within the container.(Overrides Container.CreateSite(IComponent, String).)
Releases the resources used by the nested container.(Overrides Container.Dispose(Boolean).)
Determines whether the specified object is equal to the current object.(Inherited from Object.)
Serves as the default hash function. (Inherited from Object.)
Gets the service object of the specified type, if it is available.(Overrides Container.GetService(Type).)
Returns a string that represents the current object.(Inherited from Object.)
Determines whether the component name is unique for this container.(Inherited from Container.)
The INestedContainer interface, which defines a component that logically contains zero or more other components and is owned by a parent component. The behavior of nested containers differs from a standard Container in a number of ways, including the following:class is a simple implementation of the
The site’s Name property is a qualified name that includes the owning component’s name followed by a period (.) and the child component’s name.
When the owning component is disposed, the container is disposed as well.
In addition, designers treat nested containers differently. A designer host is only interested in one container—the one associated with the host. Therefore, component add and remove events are not raised when a component is added to or removed from a nested container. However, because services flow through to the nested container, component change events are raised when a component in a nested container is changed.
This disparity in event tracking also impacts undo functionality, which is closely tied to serialization. The standard undo engine uses IReferenceService to track changes made to components. If the undo engine cannot identify a name for a component through the reference service, the engine will ignore any changes for that component. This service automatically recognizes changes to contained components only if they are exposed as public read-only properties of the same name in their owners. Otherwise, the developer must pass component change events up to the owner. For example, if a nested component’s Text property is resurfaced on its owning component as an Address property, when the Text property is changed, a property change must be programmatically made for the corresponding Address property or else that change will not be tracked by undo.
Available since 2.0
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.