In-place activation supports two different activation models—outside-in and inside-out. So far, we've been discussing the outside-in model, in which a user must double-click an inactive (loaded) object to make it UI active. If that embedded object contains other embeddings, the user has to double-click the next object down to activate that nested embedding in place, and so on.
Objects that are marked as OLEMISC_ACTIVATEWHENVISIBLE can completely avoid the need for a double click as long as the container supports the flag. But this is still an outside-in activation model—activation of the topmost object happens automatically, but the user might still need to double-click to get deeper into nested embeddings.
Some objects might want to support the inside-out activation model by marking themselves with the OLEMISC_INSIDEOUT flag. In this model, a single click on the object causes it to be activated in place. Furthermore, that inside-out object checks whether the mouse was clicked over a nested embedding that is also inside-out. If so, it activates the nested object, which then continues to do the same for however many nested objects there happen to be. In an inside-out activation model, the user can single-click to get to the innermost embedding in a stack of nested objects. This is the reason for the MSG structure passed to IOleObject::DoVerb; each object in the stack has to know where the mouse was clicked in order to know whether to activate another object.
Inside-out capability allows you to create content objects that act as data native to the container application, in which single clicks typically behave this way. Inside-out activation does require that the objects involved be small and fast to load, because you don't want to make users wait 10 seconds every time they click the mouse somewhere!
Finally, some objects might mark themselves as both OLEMISC_ACTIVATEWHENVISIBLE and OLEMISC_INSIDEOUT. If the container supports the first flag, the latter is somewhat irrelevant because the object will see the single click itself. If the container doesn't understand the difference between the in-place–active and UI-active states, but it does understand OLEMISC_INSIDEOUT, the object can still work with a single click.
If you plan to support in-place activation for an object in a local server that already works with an in-process handler, that handler must expose the necessary in-place interfaces to the container through aggregation with the default handler. The handler must also forward IOleObject::DoVerb calls properly for in-place activation to occur.