Design Specifications and Guidelines - Working with OLE Embedded and Linked Objects
A linked object can be stored in a particular location, moved, or copied, and it has its own properties. Container actions can be applied to the linked object as a unit of content. So a container supplies commands, such as Cut, Copy, Delete, and Properties, and interface elements such as handles, drop-down and shortcut menu items, and property sheets, for the linked objects it contains.
The container also provides access to the commands that activate the linked object, including the commands that provide access to content represented by the linked object. These commands are the same as those that are registered for the link source's type. Because a linked object represents and provides access to another object that resides elsewhere, editing a linked object always takes the user back to the link source. Therefore, the command used to edit a linked object is the same as the command of its linked source object. For example, the menu of a linked object can include both the Open and Edit commands if its link source is an embedded object. The Open command opens the embedded object, just as carrying out the command on the embedded object does. The Edit command opens the container window of the embedded object and activates the object for visual editing.
Figure 12.27 shows the result of opening a linked bitmap image of a horn. The image appears in its own window for editing. Note that changes made to the horn are reflected not only in its host container, the "Classical CD Review" document, but also in every other document that contains a linked object linked to that same portion of the "Horns" document. This illustrates both the power and the potential danger of using links in documents.
Figure 12.27 Editing a link source (click to enlarge image)
At first glance, editing a linked object appears similar to editing an opened embedded object; a separate primary window opens displaying the data. However, when a linked object is activated, it does not appear with the open hatched pattern. This is because the link source is in a different location. The linked object is not the real object, only a stand-in that enables the source to be visually present in other locations. Editing the linked object is functionally identical to opening the link source. Similarly, the title bar text of the link source's window does not use the convention as an open embedded object because the link source is an independent object. Therefore, the windows operate and close independently of each other. If the link source's window is already visible, the linked object notifies the link source to activate, bringing the existing window to the top of the Z order.
Note that the container of the linked object does display messages related to opening the link source. For example, the container displays a message if the link source cannot be accessed.
When the user creates a link, by default it is an automatic link; that is, whenever the source data changes, the link's visual representation changes. The user does not need to provide any additional information. Therefore, do not display a message box asking the user whether to "Update Automatic Links Now?" If the update takes a significant time to finish, you can display a message box indicating the progress of the update.
If users want to control when links are updated, they can set the linked object's update property to manual. Users must then explicitly choose a command each time they want to update a linked object. The link can also be updated as a part of the link container's Update Fields, Recalc, or other command that implies updating the presentation in the container's window.
The operations available for a linked object are supplied by its container and its source. When the user chooses a command supplied by its container, the container application handles the operation. For example, the container processes commands such as Cut, Copy, or Properties. When the user chooses a command supplied (registered) by its source, the operation is conceptually passed back to the link source for processing. In this sense, activating a linked object activates its source.
In some cases, the linked object shows the result of an operation; in other cases, the link source can be brought to the top of the Z order to handle the operation. For example, some commands on a link to a sound recording, such as Play or Rewind, appear to operate on the linked object. However, if the user chooses a command that could change the source's content (such as Edit or Open), the operation takes place in the link source.
A link can play a sound in place, but it cannot support editing in place. For a link source to properly respond to editing operations, you must fully activate the source object (with all of its containing objects and its container). For example, when the user double-clicks a linked object whose default operation is Edit, the source (or its container) opens, displaying the linked source object ready for editing. If the source is already open, the window displaying the source becomes active. This follows the standard convention for activating a window already open; that is, the window comes to the top of the Z order. You can adjust the view in the window, scrolling or changing focus within the window as necessary to make the source object easily available. The linked source window and the linked object window operate and close independently of each other.
Note
If a link source is contained within a read-only document, display a message box advising the user that edits cannot be saved to the source file.
A linked object includes a cached copy of its source's type at the time of the last update. When the type of a linked source object changes, all links derived from that source object contain the old type and operations until either an update occurs or the linked source is activated. Because out-of-date links can potentially display obsolete operations to the user, a mismatch can occur. When the user chooses a command for a linked object, the linked object compares the cached type with the current type of the linked source. If they are the same, the linked object forwards the operation on to the source. If they are different, the linked object notifies its container. In response, the container can either:
In either case, the linked object adopts the source's new type, and subsequently the container displays the new type's operations in the linked object's menu.
Fundamentals of Designing User Interaction
Design Specifications and Guidelines