At some point during its lifetime, an object will need to remove all of the user interface it created during UI activation and remove from the container the window that is created for the in-place–active state. The container controls which type of deactivation happens by calling either IOleInPlaceObject::UIDeactivate or IOleInPlaceObject::InPlaceDeactivate.
UI deactivation means that the object first calls IOleInPlaceSite::OnUIDeactivate, then removes its tools, and then unravels the shared menu. In-place deactivation implies UI deactivation if the object is UI active. UI deactivation is followed by the removal of the object's window from the container, a call to IOleInPlaceUIWindow::SetActiveObject with NULL, a call to IOleInPlaceSite::OnInPlaceDeactivate, and finally the release of the container's in-place interface pointers.
I want to share a few things that Microsoft learned about in-place activation in usability tests involving test subjects who were accustomed to working with Microsoft Word and Microsoft Excel. The usability testers created a simulation in which an Excel spreadsheet object would be activated in place inside Word. At first, the usability designers thought some serious confusion might occur when the menus and toolbars began to switch around. What they actually found was quite surprising. When subjects activated the spreadsheet object in place, they immediately recognized Excel's row and column headings that appeared around the object. Without noticing what had happened, they went along using Excel's toolbar and formula bar (which had quietly appeared in place of Word's toolbar and ribbon) as well as Excel's menus (which had quietly merged with Word's). Only after doing their jobs (that is, manipulating the spreadsheet) for a number of minutes did the subjects begin to notice that things had changed. This was a surprise because the testers thought it would be obvious that stuff was switching around. But because the users were focusing so intently on the object they wanted to edit, they weren't even looking at the menus or the toolbar. When the object changed from a simple presentation to something that looked like an Excel spreadsheet, their Excel training kicked right in without a hitch.
On the whole, deactivation is simpler than activation. When the container deactivates an object, that container knows that it has regained control of the toolbar space, so it simply makes its tools visible again. Unwinding the menu is accomplished by the object removing its menu items, calling IOleInPlaceFrame::RemoveMenus, and then calling the Windows function DestroyMenu to match the earlier CreateMenu. Removing the in-place editing window is simply a matter of calling SetParent with one of the server's own window handles.