In-place or
in situ
editing is like drive-through editing: You don't actually go inside the restaurant, you just stop and get what you want through a window. With in-place editing, the container application's interface changes to that of the server application that created the object you're editing.
Many Windows 95 applicat
ions already support in-place editing--certainly all the Microsoft Office products do. But many others don't. For example, even though you can embed and edit in-place a Lotus Word Pro 96 document from within Office, you can't do the same with Lotus 1-2-3 release 5. Instead, Office opens a separate 1-2-3 window when you try editing a 1-2-3 spreadsheet object. The embedded spreadsheet is
grayed out
and its contents copied into the 1-2-3 window. When you've completed your alterations, 1-2-3 asks if you want to have your changes copied back into the object you've been editing.
Objects May Appear Larger Than They Are
When one object is embedded in another, OLE has to pull off some complex moves. If you do some exploring, you'll find evidence that many application designers apparently did not have in mind all the activities that OLE would allow. The result is that things don't always work the way you thought they would, particularly when it comes to the way an embedded
object's data gets presented.
Open a Microsoft Word 7.0 document and enter some text. Then embed an Excel 7.0 worksheet in the Word document. One click on the Excel object will generate a box outline with attached drag handles. Click and drag the handles and watch what happens (
see the screen
).
Sometimes the scaling works and the spreadsheet font looks reasonable; sometimes it doesn't. Admittedly, we're pulling some esoteric moves: How often does anyone resize an embedded spreadsheet to bizarre dimensions? But just resize it a little and double-click on it to put the spreadsheet into in-place editing mode, and the window that opens into the object will likely reveal a suddenly magnified portion of the spreadsheet. It's as if Excel knows you did some resizing on the embedded object, doesn't know the details of the resize operation, and just produces a magnified view to impress you.
Apparently, when you resize horizontally and switch to in-place editing, the system pi
cks the closest font with the proper horizontal dimension. Unfortunately, this approach produces an altered vertical dimension. So, if you made your spreadsheet object unusually wide, in-place editing produces an edit window with a font that's unusually tall as well. The effect is orthogonal: If you resize the object so that it's tall, the edit-in-place window will be sized with a font that's wide, too.
Paging Mr. Excel
The term "logical object pagination" refers to OLE's supposed ability to display data for an object too large to fit on a page of the container application's data presentation. Try this: Create a reasonably long Excel spreadsheet, 150 rows or so. Embed the object in a Microsoft Word document, just beneath a couple of sentences on the first page. Excel (or Word, it's hard to figure out which program is responsible for this) appears unwilling to place the top of the spreadsheet object anywhere but at the start of a page. Since you've already typed a couple of lines of te
xt, the embedded object creates an unusable hole extending from the end of the text you've typed to the end of the first page. The embedded object begins at the top of page two.
Furthermore, the spreadsheet has been "clipped" to fit onto the page; it will not cross the boundary to the next page. You'll be able to see only about 70 or so lines of the Excel sheet, though you can edit the spreadsheet in-place, and scroll bars let you get to the rest of the "hidden" data. Try hard as you may to resize the sheet onto the next page, Excel refuses.
See the screens
to view this phenomenon.
Remember the unusable hole? If you resize the spreadsheet to make it smaller--just enough to fit on the remainder of page one--the whole thing snaps back to just under the text. Blink and you'll miss this.
Where Was I?
Resizing an embedded object so it is larger than the container's viewing window area brings up annoying behavior. When you activate in-place editing for su
ch an object, the container appears unable to track the insertion point of the contained object.
Let's return to the overly large spreadsheet object in the preceding section. If you double-click on the object to perform in-place editing, the object's window will appear, with scroll bars. But if you move the insertion point up or down so it passes outside Word's window, Word won't "track" the insertion point. In other words, the inner window scrolls properly, but the outer window doesn't. Because of such oddities, our advice is as it's always been: frequent backups.
screen_link (45 Kbytes)
screen_link (26 Kbytes)
screen_link (44 Kbytes)
The OLE Experience
