You should keep in mind three primary considerations when designing and implementing an in-place–capable container.
First, you have limited command availability: not all of your menus will be available, you might not have your toolbars available, and you will not have first crack at accelerators. So ask yourself some questions. What functions do you want to have available during an in-place session? Are those functions on menus that you will retain during the session? Are there commands that are available only on a toolbar so that they will be inaccessible during the session? What accelerators correspond to menu items that you will not retain? Do you need to define separate menu and accelerator resources to load during a session? Can you modify your editing toolbar in such a way that if you are allowed to retain it during a session, you can remove those commands that you do not retain? Your answers to these questions might lead to significant code changes, but those are best done now, before attempting to work with in-place activation any further.
The second consideration is that you will be sharing the menu with the object. This means that your particular menu items can appear anywhere on the menu. You cannot depend on any particular item having any particular position. This will likely affect WM_INITMENU and WM_INITMENUPOPUP message handling—applications typically use the menu positions passed with these messages for enabling or disabling specific menu items—for example, Edit Paste. To work independent of specific positions, either you'll need to maintain an array of the current positions of the top-level items that you place in the shared menu or you'll need to modify your code to work solely on menu handles, which are also passed with WM_INITMENU[POPUP] messages and provide a much more robust way to identify a specific menu item.
The third consideration is the negotiation of space for the object's in-place tools. How easily can your container handle foreign tools in the frame and document windows? Can you resize whatever window occupies the client area of your frame and document windows? Can you resize them in any direction? Can you resize them while keeping the contents at the same absolute screen position? How small can they be? Is there a point at which you would restrict the border space allowed for an object? Are there spaces in the frame or document client areas that should never be overlapped by an object (especially those areas that are drawn and not separate windows)? Do your tool windows use WS_CLIPSIBLINGS to keep them from interfering with object tools? Do you have a status line? When the frame or document window is resized, do you always resize the client to a specific position?
Grist for the mill. During an in-place session, you are responsible for respecting the space you allow an object, which means not drawing over it, keeping your client-area windows inside the space left over after the object's allocations, and ensuring that you resize the client windows correctly when the frame or document is resized. Thinking about the impact of sharing space on an arbitrary basis, and modifying your container code to handle it, is well worth the effort now before things get complicated.