Long ago, in an era of greater simplicity, when the OLE Design Specification was only 50 pages long, there was a new idea called in situ editing. Instead of forcing you to edit an embedded object in a separate server window, in situ editing—an extension of normal activation—let you edit an object while remaining in the context of the compound document. The Latin phrase in situ means "in the natural or original position." Simple enough.
But the marketing types at Microsoft looked at in situ editing and, with good, sound intentions, changed it to in-place editing. OK, that's cool. The change got rid of that funny Latin stuff and made the term more comprehensible to us programmers who didn't break 600 on the SAT verbal. Everyone understood and was happy to get working on it.
In a burst of pure reason, marketing figured that the word editing was much too specific for compound documents because certain objects—for example, video objects—are more apt to be played in place instead of being edited. This led to the term activation, so this new idea was rechristened in-place activation. But that wasn't the end of the matter. Marketing just can't leave well enough alone.
Along came the tide of "Visual This" and "Visual That"—Visual Basic, Visual C++, and so on and so forth. Everything suddenly had to be visual in some way. It was cool. It would hook end users the same way free T-shirts hook hungry programmers at software development conferences. Marketing rode the wave and brought on visual editing, even going as far as to slap on the prominent trademark symbol(™).
Of course, with this latest term, the word editing again reared its ugly head, but then the name changes stopped. I fully expected visual editing to give way to visual activation, and after visual fell out of vogue, visual activation would revert to in situ activation and then back to in-place activation because us programmers still can't break 600 on the SAT verbal.
So I stick with the name in-place activation for the technology that is the subject of this chapter and the next, calling it in-place simply for convenience. We'll start this chapter with a look at a typical in-place session for an embedded object, given that both the container and the object (and the object's server) support this capability. This will show us the in-place interfaces that are involved and how they work together to merge the user interface in a way that looks a little weird at first, but one that has proved itself in usability testing. Much of in-place activation is about merging the object's user interface with the container's. Doing this brings the object's tools to the object instead of taking the object to the tools.
We'll also examine some additional considerations, including keyboard accelerators, context-sensitive help, Undo operations, and the ability to have multiple in-place objects active at the same time. In this chapter, we'll see the implementation steps for an in-place–capable container, using Patron once again as our sample. Chapter 23 will explore the object side of the picture. These two chapters set the stage for OLE Controls because controls, being self-contained units of functionality, are almost always in-place active. And with controls, the term in-place activation certainly fits because I have a hard time understanding how I would visually edit a control. Maybe I still need to learn Latin.