Now that we've demonstrated how embedded applications work, we must point out the drawbacks of this approach so we can explain the concept of components in PenPoint. From the preceding discussion it should be clear to you that embedded applications are somewhat costly in memory and proces-sor cycles: each embedded application requires its own process and a sepa-rate document directory. (These are not costs without merit: because the embedded applications run in their own processes, even if they crash, the embedder can continue running.) While these are perfectly reasonable for normal embedded applications (for example, embedding a drawing or table inside a word processor), they are too costly for embedded data types entail-ing a small amount of application instance datR
PenPoint components, on the other hand, are a lighter-weight alternative to embedded applications. Because components execute within their host application's process and file their data in the host application's data file, they don't need a process or document directory of their own. Components are instances of subclasses of clsEmbeddedWin and are therefore embedded windows themselves. PenPoint includes three predefined components:
clsAppWin (the class used for the wrapper window B in our example), Goto buttons, and Signature Pads. Applications may define their own additional components.
What Your Application Must Do
Don't be too concerned if all this seems like a lot of work: it would be if not for PenPoint's strong object orientation. But clsApp and clsEmbeddedWin handle virtually all of the work for you with appropriate default behavior. You don't need to do any work whatsoever to be an embeddee. To embed, the typical embedder needs to respond only to the four clsEmbeddedWin mes-sages mentioned earlier.
Embedder applications only rarely need to modify the default clsApp behav-ior for starting and stopping processes. One exception is an embedder that hosts dozens or hundreds of embeddees. Such an embedder would probably
want to manage the startup and shutdown processes of its embeddees. Otherwise, it would find all embeddees running all the time. This is just what clsSectApp (the Notebook's Table of Contents) does: it modifies startup behavior to be the opposite of the running process for every embeddee. In this way the only embeddee with a process is the current page (and any floating pages).
Embedded Window Marks
PenPoint keeps track of embedded documents using embedded window marks. A mark is a special data structure containing
• the UUID of the document containing the mark
• the UUID of the component within the document
• a component-specific token that specifies a location within the component
• a label for the mark
Both Goto buttons and the traversal engine use these marks to point to embedded windows.
The Problem of Traversal
Many document operations must include and take into account the contents of child embedded windows. The three most common such operations are search (and its relative, search and replace), print, and spell check, but there could conceivably be many others. In each case, the parent application must know something about the contents of the windows created by other applica-tions and embedded within the parent. At the very least the parent application must be able to find out if the child application defines behavior for the task at hand. For example, it is unlikely (although not impossible) that a painting program would include the notion of spelling checks, because its contents normally are not viewed as text. Such an application might simply tell a proof-reading process to skip over it. But its contents determine this.
This need poses some obvious problems with windows containing docu-ments of different types. Content-dependent behavior is simple in a simple
Recursive Live Embedding of Applications
document, but it becomes increasingly complex when we deal with compound documents. PenPoint's answer to the problem is the notion of traversal. Tra-versal works with both the window and file system hierarchies to visit all user data in the correct order regardless of the complexity of the embedding.
Traversal is actually implemented in PenPoint using a driver-slave model (see Figure 8-8).
The process shown in Figure 8-8 is a typical one, but is not necessarily indicative of the way all traversals are handled. For example, some traversals might not require the slave to locate any data. In that case, the steps associ-ated with that processing are of course eliminassoci-ated from the steps shown in the figure. Regardless of the details, the driver (the object requesting traversal, generally an application or the PenPoint traversal engine which we'll discuss later) and the slave (either a document or a component) interact to visit all embedded documents and scan all data within a specified range.
In many cases, the user determines the scope or method of traversal by choices or commands. The user is not aware of the traversal issue, but by selecting operations to be performed and defining their scope, the user can playa role in determining the behavior of the process.
As you can see from Figure 8-8, the driver-slave model keeps the traversal process in synchronization through a mechanism called a traversal context.
This context is a protocol between the driver and all the slaves it encounters as it carries out its processing on a parent document and its child embedded windows. You can think of this context as a structure that contains the scope of the traversal and its direction as well as the current position within the scope. As traversal processing takes place, the current position is updated to keep the driver and slave in synch.
The traversal process, like most PenPoint processing, uses a message-sending model. The driver sends messages to each slave it encounters.
Slaves respond to these messages, depending on the traverse style defined in the traversal context. The four types of behavior an application can define for its instances are
• Don't enter any embedded windows.
• Enter all open embedded windows.
• Enter all embedded windows.
• Invoke a call-back routine.
Driver
Encounters a child embedded window
Sends message telling slave to find data
Sends message telling slave what to do with found data
Transversal ends
Slave
Is end of scope reached?
Carries out operation;
notifies driver
Yes Terminates and notifies driver
Figure 8-8 Driver-Slave Traversal Model