In cases other than playing a sound or a video clip, activation of an object generally requires that the object display another window in which an operation such as editing takes place. For example, if you have a table from a spreadsheet embedded within a document and you want to edit that table, you would need to get the table back into the spreadsheet application to make changes. Right?
Not necessarily. OLE Documents includes a feature called in-place activation (also known as visual editing when you talk to marketing folks), which is a set of interfaces and negotiation protocols through which the container and the object merge elements of their user interface into the container's window space. In other words, in-place activation allows the object to bring its editing tools to the container instead of taking the object to the editing tools. This includes menus, toolbars, and small child windows that are all placed within the container.
The central idea of in-place activation is to create a document-centric work environment for the end user. The simple activation model of embedding and linking is a more application-centric model, in which data is taken to the application for editing. Again, in-place activation brings the editing to the document. Visually, the user never has to leave the document itself—everything is right there.
Chapters 22 and 23 cover the necessary additions to both containers and objects. The changes are almost entirely manifest in adding various interfaces that start with the IOleInPlace prefix. For example, a container site supports in-place activation by adding IOleInPlaceSite, and when activating itself, an object will query for this interface to see whether it should become active in-place or in another window. Because of this query step, objects that support in-place activation work perfectly well with containers that don't, and as soon as the container is revised to support the additional interface, the same unmodified object begins immediately to activate in place, even though it never did before. The object itself implements IOleInPlaceObject to indicate that it is in-place capable. Other in-place interfaces are implemented in other areas of the container and object in order to make the user interface negotiation work.
In-place activation is not limited to activating just one object at a time, or to activating objects only on user command. Objects can mark themselves to be activated in place whenever visible but without bothering the menu or toolbars. This means that each object can have an editing window in its space in the container so that it can respond immediately to mouse clicks and the like. Only one object, however, can be UI active, which means that its menus and toolbars are available and that it gets a chance to process keyboard accelerators. So while many objects might be active at once, the UI active object switches as the user moves around within the document.
With many objects active at one time within a document, you can start to imagine how useful it would be if some of those objects were things like buttons or list boxes. Why, you could create forms with such objects, and you could create an arbitrary container that could hold objects from any source and benefit from all the other integration features of OLE! This is exactly why OLE Controls technology has been invented.