The addition of in-place activation to an embedded object server is only a small portion of the overall server structure but one that provides great user benefits. This chapter follows the implementation steps for adding in-place support to the Cosmo sample and also provides an in-place–capable version of the Polyline server.
The first step in such an implementation is to prepare the object and its server for the implications of merging user interface elements with a container. This can affect how the server deals with its menus, its toolbars, and its own child window classes. Assumptions that you can make when creating a stand-alone application no longer apply when in-place activation is involved. Simply said, menus, toolbars, and child windows might appear in a document or a frame window that is not owned by the server itself. This means that you have to be careful routing messages and specifying how the rest of the server code deals with these pieces of user interfaces.
The remaining steps mainly involve the implementation of IOleInPlaceObject and IOleInPlaceActiveObject, modifications to IOleObject::DoVerb, and all the work necessary to create the in-place UI, including keyboard accelerators. In addition, a number of small considerations require handling, such as Undo operations, context-sensitive help, window resizing and activation, document scrolling, object resizing, status line text, and the handling of modeless pop-up windows. In-place–capable objects can also choose to mark themselves with OLEMISC_ACTIVATEWHENVISIBLE and with OLEMISC- _INSIDEOUT. This choice really has little impact on the object itself. These flags primarily tell the container when to activate the object in the first place.