WO1993003473A1 - Systeme d'edition en contexte a outil d'encadrement - Google Patents

Systeme d'edition en contexte a outil d'encadrement Download PDF

Info

Publication number
WO1993003473A1
WO1993003473A1 PCT/US1992/006634 US9206634W WO9303473A1 WO 1993003473 A1 WO1993003473 A1 WO 1993003473A1 US 9206634 W US9206634 W US 9206634W WO 9303473 A1 WO9303473 A1 WO 9303473A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
window
kernel
state
documents
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US1992/006634
Other languages
English (en)
Inventor
Michael Staw
Mark S. Simonsen
Michael Houle
Richard Frank
Bruce Rosenblum
Kenneth A. Tepper
Steve Sisak
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BEAGLE BROS Inc
Original Assignee
BEAGLE BROS Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BEAGLE BROS Inc filed Critical BEAGLE BROS Inc
Publication of WO1993003473A1 publication Critical patent/WO1993003473A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/14—Display of multiple viewports
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems
    • G06F16/94—Hypermedia
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents

Definitions

  • the present invention relates to the editing of multiple documents and, more particularly, to editing a composite document having one or more embedded documents. Description of the Prior Art
  • the computer user In most general purpose computer systems, the computer user is provided a mechanism whereby text documents can be created and modified at will.
  • the mechanism for such text editing is most commonly referred to as a word processor which by this definition is a type of computer program.
  • certain types of graphic objects can be edited with line drawing or "draw” programs and other graphic objects reguire less sophisticated editing features which are satisfied by so-called "paint" programs, and some numeric objects can be edited with spreadsheet programs.
  • AmiPro Version 1.21, licensed by Sa na, permits a user to define a region of the document, select an object type and create new objects of the selected type in the defined region.
  • AmiPro does not create a separate window for the defined region and, moreover, saves the objects of the defined region and the objects outside of the region, together in a single document.
  • One spreadsheet program EXCEL 3.0 licensed by Microsoft Corporation, provides the user with the capability to create a histogram document in a window while the underlying spreadsheet document is displayed in another window. Nonetheless, the histogram is not related to, or displayed at, any particular location in the spreadsheet.
  • the present invention satisfies the aforementioned needs by providing an in-context editing system with a frame tool.
  • the invention allows users to mix documents of selected object types and place a document or document portion in any location(s) in another document to form a composite document.
  • the user of the in-context editor (ICE) can edit the contents of an embedded or subscriber document without leaving the context of the subscribing document in which the subscriber document is embedded.
  • ICE in-context editor
  • the frame scrolls with the parent.
  • the present invention provides, in a computer, a method of editing a plurality of documents, comprising the steps of:displaying at least a portion of a selected first one of the documents; linking a selected second one of the documents to the first document; displaying at least a portion of the second document simultaneously with said displaying of the first document; positioning the second document at a selected location in the first document so that together the selected documents are displayed as a composite document; and modifying the second document while the composite document is displayed.
  • One aspect of the present invention provides, in a computer, a method of creating a composite document, comprising the steps of: displaying at least a portion of a first document containing an object, selecting a frame in the displayed first document portion, selecting an object type from a plurality of object types, creating a second document for containing an object of the selected object type which is displayable in the frame so that together the documents are displayed as a composite document, linking the second document to the first document, and creating an object of the selected object type in the frame while the composite document is displayed. Furthermore, the method provides for modifying an object in the second document.
  • Figure 1 i ⁇ a functional block diagram of a representative computer used by one preferred embodiment of the present invention
  • Figure 2 is a screen display of "windows" that may be produced on the video display of the computer shown in Figure
  • Figure 3 is an exemplary diagrammatic view of document linking as constructed by the present invention.
  • FIG. 4 is a detailed diagram of a preferred document linkage constructed by the present invention.
  • Figure 5 is a screen display of a composite document formed from a subscriber document and an intermediate document, the subscriber and intermediate documents having nonhomogeneous objects (i.e., text and graphics), as provided by a preferred embodiment of the present invention
  • Figure 6 is a hierarchical chart of the preferred class architecture in one preferred embodiment of the present invention
  • FIG. 7 is a flow diagram of the "TLocalKernel: :EventLoop" function of the presently preferred embodiment of the in-context editor (ICE) of the invention
  • Figure 8 is a flow diagram of the "TLocalKernel: :DispatchOSEvent” function used by the in- context editing function of Figure 7;
  • Figure 9 is a flow diagram of the "TLocalKernel: :DoMouseDown” function used by the in-context editing function of Figure 8;
  • Figure 10 is a flow diagram of the "TDocumentWindow: :DoMouseDown" function used by the in-context editing function of Figure 9;
  • Figure 11 is a flow diagram of the "TFrame: :DoMouseDown" function used by the in-context editing function of Figure 10;
  • Figure 12 is a screen display of the same composite document as illustrated in Figure 5, which is produced after activating and editing the intermediate document using the presently preferred in-context editor (ICE) of the invention;
  • ICE in-context editor
  • FIG. 13 is a flow diagram of the "TSubscriptionList: :HitTestFloaters” function used by the in- context editing function of Figure 11;
  • Figure 14 is a flow diagram of the "TSubscriptionList: :LaunchPublisherFromToken” functionusedby the in-context editing function of Figure 11;
  • FIG. 15 is a flow diagram of the "TSubscriptionList: :DrawFloaters” function used by the presently preferred embodiment of the in-context editor (ICE) of the invention;
  • Figure 16 is a screen display of the same composite document as illustrated in Figure 12, after the composite document is scrolled by the presently preferred embodiment of the in-context editor (ICE) of the invention;
  • Figure 17 is a flow diagram of the "TDocument::CloseLink" function used by the in-context editing function of Figure 10; and
  • Figure 18 is a screen display of the same composite document as illustrated in Figure 12, after the window containing the intermediate document is made invalid.
  • Figure 19 is a screen display of a portion of a first document having a frame selected using the presently preferred in-context editor (ICE) of the invention
  • Figure 20 is a screen display of the first document and frame, of Figure 19, with a list of various object types presented for selection;
  • Figure 21 is a screen display of the first document and frame, of Figure 19, after an object type has been selected and a second document has been created;
  • Figure 22 is a flow diagram of the "TToolbar: :DoMouseDown" function used by the in-context editing function of Figure 9;
  • Figure 23 is a flow diagram of the "TLocalKernel: :HandleCreateFrame" function used by the in- context editing function of Figure 22;
  • Figure 24 is a flow diagram of an extended portion of the "TFrame::DoMouseDown” function, shown in Figure 11, which relates to the frame mode of the present invention
  • Figure 25 is a flow diagram of the "TLocalKernel: :CreateDocInFrame” function used by the portion of the in-context editing function of Figure 24;
  • Figure 26 is a screen display of the first document and frame, of Figure 19, wherein the frame includes the second document of the selected object type having draw objects;
  • Figure 27 is a screen display of the composite document of Figure 26 wherein the in-context editor is no longer in frame mode;
  • Figure 28 is a screen display of the composite document of Figure 27 after modification of the second document as simultaneously displayed in the child window;
  • Figure 29 is a screen display of the composite document of Figure 28 showing the composite document of first and second documents displayed in a single window.
  • FIG 1 illustrates the functional components of a computer, of the presently preferred invention, generally indicated at 100.
  • the functional block diagram represents a Macintosh SE/30 manufactured by Apple Computer of Cupertino, California.
  • the preferred computer 100 may be referred to herein as a Macintosh, it will be understood by computer technologists that many other computers may be used in place of the one described.
  • the preferred computer 100 comprises a microprocessor 102.
  • the microprocessor 102 is one of the Motorola 680x0 family, such as the 68030 in the Macintosh SE/30.
  • the microprocessor 102 executes the instructions of computer programs (not shown) stored in a read-only memory (ROM) 104 and/or a random-access memory (RAM) 106.
  • the instructions are communicated to the microprocessor 102 via an address and data bus 108 which is 32 bits wide for both address and data.
  • the ROM 104 in the preferred computer 100, comprising 256 kilobytes of memory, stores the Macintosh Operating System, or "OS".
  • the on-board RAM 106 is expandable from 1 Megabyte up to 128 Megabytes and stores application programs and data which are included by the in-context editor (ICE) of the present invention.
  • a coprocessor 110 such as, for example, the Motorola 68882 floating-point unit, advantageously improves the performance of applications which use many floating-point operations such as graphics processing that may be included in the present invention.
  • the ICE of the present invention can be magnetically encoded on a portable media such as a floppy disk (not shown) which may be placed in a floppy disk drive 111.
  • the floppy disk drive 111 is controlled by a floppy disk drive controller 112 which principally communicates with the components 102, 106 across the buses 108.
  • the ICE can be selectively loaded into the RAM 106 and executed by the microprocessor 102.
  • the ICE can be transferred and stored on a hard disk drive 114.
  • the hard disk drive 114 is interfaced to other computer components, principally the components 102, 106, by way of a Small Computer System Interface (SCSI) controller 116, which is an industry standard interface that provides high-speed access to peripheral devices.
  • SCSI Small Computer System Interface
  • a user most often provides input data to the computer 100 by moving and "clicking" a mouse, or other pointing device 118 and typing on a keyboard 120.
  • the input devices 118, 120 communicate with the computer 110 through an input device controller 122.
  • the mouse 118 guides a pointer (indicated in Figure 2 by the arrow 133) across a video display 124.
  • the video display 124 is refreshed by the computer 100, via a video controller 126, so as to apprise the user of the current state of processing.
  • Figure 2 illustrates a representative screen display that may be produced on the video display 124 of the computer 100
  • Figure 1 using either the present technology or the in- context editing system of the present invention.
  • the preferred embodiment of the invention includes a desktop, or
  • windows interface that is a metaphor for working with documents on a desktop.
  • One such interface is provided for
  • the screen display of Figure 2 includes a menu bar 130, which is a horizontal strip at the top of the screen, that includes one or more menu titles such as the title "File” indicated at 132.
  • a pointer 133 can be selectively moved across the screen (via movement of the mouse 118 of Figure 1) and placed on top of a menu title. The user may then depress a button on the mouse 118, called a "click", and a pull-down menu such as the one at 134 is displayed to the user.
  • the menu 134 includes various operations (or verbs) that may be carried out on a preselected object (or noun) .
  • the desktop 136 includes icons, which are small pictures that represent objects to be worked on, such as the trash can icon 138.
  • icons are small pictures that represent objects to be worked on, such as the trash can icon 138.
  • disk icons can be opened as windows into documents which appear to rest on the desktop 136.
  • the screen display of Figure 2 illustrates two overlapping windows "on" the desktop 136.
  • An inactive window 140 wherein the inactivity is indicated to the user by a lack of shading at the edges of the window including a lack of "racing stripes" in the top edge of the window, has a content area 141 that includes textual data or objects.
  • the inactive window 140 underlies an active window 142 which has a content area 143 showing graphical data or objects.
  • only one window is active at a time (always at the top of, or in front of, any overlapping windows) and the active window is allowed to have operations performed on its objects.
  • the area of window surrounding the contents is sometimes referred to as the window frame, although frame may also refer to the entire window.
  • the applications e.g., word processor and paint programs, have completely independent windows that have no "knowledge" of one another.
  • the structural elements of the window frame which surround the content area of a window, are highlighted in the active window 142. Most of the structural elements can be selected by clicking the mouse 118 ( Figure 1) or using the mouse 118 to "drag" the element across a portion of the video display 124.
  • the mouse 118 can be used to drag a displayed element by positioning the pointer 133 on the element, depressing the mouse button, and moving the mouse 118 in the desired direction while holding the button down.
  • a close box 144 (upper left corner of window, in title bar 146) , which when clicked closes the window so that whatever previously underlaid the window is now displayed; a title bar 146 (horizontal strip at the top of the window) for indicating the document being displayed in the window and for dragging the window; a zoom box 148 (upper right corner of window, in title bar 146) which when clicked makes the window enlarge or reduce to one of two preselected sizes; a vertical scroll bar 150 (vertical strip on the right side of the window) which represents the vertical dimension of the entire document; a size box 152 (lower right corner of the window) which when clicked allows the user to "grow" the window or change its size in selected increments; a horizontal scroll bar 154 (horizontal strip at the bottom of the window) which represents the horizontal dimension of the entire document; a scroll box 156 (one in each scroll bar 150, 154) which when dragged within the scroll bar "moves" the document in the dragging direction; and
  • material from a publishing document called a publisher
  • a publisher can be copied and pasted to one or more subscribing documents (the material is then termed a subscriber) such that when the original material is updated in the publishing document, the changes are automatically reflected in the subscribing documents.
  • a publishing document 162 preferably stored on the hard disk 114 ( Figure 1)
  • Figure 1 contains a set of bar chart objects.
  • the user selects a publisher 164 by outlining certain bar chart material to be published from the document 162 using the mouse 118 and the video display 124.
  • the selection function is accomplished in a window such as the active window 142 shown in Figure 2.
  • the publisher 164 is saved in an edition file 166 on the hard disk 114.
  • the user opens a window for a first subscribing document 168 that is preferably stored on the hard disk 114.
  • the window is opened by clicking the "File” title in the menu bar 130, and then selecting "New” for a new document or choosing an existing document that is typically stored on the hard disk 114 ( Figure 1) .
  • the subscribing document 168 i ⁇ in the example, a text document that is manipulated, or edited, with a word processing program.
  • the user employs the mouse 118 to create and position a subscriber 169 in the document 168.
  • the subscribing document 168 now containing text, and a link to the bar chart objects saved in the edition file 166, is saved back to the disk 114.
  • a similar procedure is followed for a second subscribing document 170 and an associated subscriber 171. Both of the subscribers 169, 171 are now linked to the edition file 166 which in turn is linked to the publishing document 162.
  • the publishing document 162 is now opened in a window, and the bar chart objects in the publisher 164 are modified by a bar chart editor (not shown) , the modifications are saved in the publishing document 162, as well as the edition file 166.
  • the subscribing documents 168, 170 are next printed, displayed, etc., the subscribers 169, 171 will contain the modifications made previously in the publishing document.
  • the presently preferred in-context editor (ICE) of the invention employs a linking concept that in some ways is similar to the publish-and-subscribe concept just discussed, and that is compatible with Apple's System 6 and System 7 software. For example, in the present invention, multiple subscribing documents may subscribe to the same subscriber.
  • a publishing document 174 contains a publishing document 174.
  • the user-definition of the publisher 176 causes an intermediate file 178 (which is to be distinguished from an edition file) to come into existence.
  • the intermediate file 178 contains a segment 179 of the published document 174, a publisher record 180 which refers to the location of the segment 179 in the publishing document 174, a file specification (FSSPEC) record 181 (used by System 6 software) identifying the publishing document 174, an alias record 182 (used by System 7 Software) identifying the publishing document 174 more robustly than by file specification, a preview 183 that is a miniature picture of the published segment 179 (for display to the user by the "Getlnfo" command in the "File” menu or the "Subscribe to" command in the "Edit” menu) and a module descripter 184 that identifies the module that created the segment 179, e.g., a specific word processing program.
  • FSSPEC file specification
  • alias record 182 used by System 7 Software
  • FIG. 5 illustrates a screen display that is produced on the video display 124 ( Figure 1) by the preferred in-context editor (ICE) of the present invention.
  • the ICE include ⁇ a set of modules, presently including: word processor, database, spreadsheet, chart, draw, paint and communications.
  • the ICE modules may communicate to the desktop interface via a kernel program which will be described below. Since the general function ⁇ of the ICE modules are well understand in the present technology the specific ⁇ of each will not be discus ⁇ ed except to say that each module interacts with a specific window and document via the kernel.
  • the ICE display looks similar to the desktop interface display previously discussed with respect to Figure 2. However, in this display, a parent window 190 shows that two documents, a subscriber document 192 comprising a paint object 193 created with a paint program (not shown) , and a subscribing document 194 having text objects, have been integrated into a single, composite document (but each member document of the composite document is stored at a different logical location of the disk 114 ( Figure 1).
  • a tool bar 196 showing operations for text objects, reflects the fact that text editing may at the time be accomplished in the context of the subscribing document 194. For example, text may be inserted at the insertion point 198 when the user types on the keyboard 120.
  • a similar display could be generated with the publish-and-subscribe feature of the prior technology.
  • the prior technology would not allow editing the object in the subscriber document 192 in the context of the subscribing document 194, or in other words, editing the embedded document without leaving a view into the embedding document.
  • the user may initiate in- context editing, (or editing in place without leaving a view of the composite document) , by first moving the pointer 200 as indicated by the arrow 202 inside of the subscriber document 192, and then double clicking the button on the mouse 118.
  • Figure 6 illustrates the presently preferred class architecture of the in-context editor.
  • a "class” is a definition of a data type that specifie ⁇ the representation of objects of the class and the set of operations that can be applied to the objects.
  • An object of a class is a region of storage or memory.
  • the notion of a "class” will be understood by those skilled in the object-oriented programming technology and, in particular, by those familiar with the "C++" programming language. Clas ⁇ e ⁇ may be more fully comprehended by reference to The Annotated C++ Reference Manual, Ellis, Margaret and Stroustrup, Bjarne, Addison-Wesley Publishing Co., 1990.
  • a "bakery class” would provide a mulberry pie sale operation to allow a customer to purchase a mulberry pie without any knowledge on the part of the customer as to how pies were stored at the bakery, or how the customer's pie was selected from a number of different pies.
  • TObject class 206 provides the methods for objects to be created, the strategy for dynamic memory allocation and deallocation, and the method for receiving events and passing events between objects.
  • An event is a significant, asynchronous change in the system that requires processing. In this sense, the present invention is "driven" by events since nothing happens in the absence of an event.
  • An example of an event is a click of the mouse 118 ( Figure 1), i.e., the depression of the button.
  • a TEventHandler class 207 is derived from TObject 206. TEventHandler 207 provide ⁇ an object which can react to an event that is sent by another object. TEventHandler 207 thus provides a common event passing interface between its subcla ⁇ e ⁇ .
  • a TPublicationList class 208 and a TSubscriptionLi ⁇ t cla ⁇ 209 are also derived from TObject 206.
  • TPublicationList 208 is a clas ⁇ that manages the links to document sections, or publisher ⁇ , that have been published by a publishing document.
  • TSubscriptionList 209 is a class that manages the ⁇ ub ⁇ cribers, or embedded documents, of a subscribing document.
  • the remaining classes are subcla ⁇ ses of TEventHandler 207.
  • the TDocument 210 and TModule 212 cla ⁇ es are classes from which authors of ICE modules may derive classes to send and receive event ⁇ to objects not in their own clas ⁇ .
  • the TKernel 214, TMenu 216 and TMenuBar 218 classe ⁇ handle the de ⁇ ktop interface (as described above) except for windows.
  • a TVisibleThing class 220 maintains the entire visual hierarchy on the desktop that defines windows.
  • a TWindow class 222 is a subclas ⁇ of TVisibleThing 220.
  • TWindow 222 handles events that relate to a window opened by a dynamically allocated copy of a TWindow class.
  • TDocumentWindow 224 is a subcla ⁇ s of TWindow 222. Since the ICE allows multiple documents to be associated with a parent window, such as 190 in Figure 5, TDocumentWindow provides the mechanism to di ⁇ patch an event through the pane (the contents of a window may be viewed in up to four different panes but typically there is a one-to-one correspondence between the content area and a ⁇ ingle pane) where the subscriber i ⁇ located.
  • TPane 226 i ⁇ a subclass of TVisibleThing 220.
  • TPane 226 handles events that are directed to a pane of a window.
  • TFra e 228 is a container clas ⁇ for up to four pane ⁇ .
  • TDocumentView 230 is a subclass of TPane 226 that links a document to a visible area.
  • TVirtualPane 232 is a subclas ⁇ of TDocumentView 230 that doe ⁇ coordinate system mapping for modules that require such mapping, presently the paint and draw modules.
  • the ICE module ⁇ e.g., word proce ⁇ or, each of which may be associated with a different type of document
  • ICE kernel which is a portion of the ICE software.
  • the kernel maintains the knowledge or state ⁇ of in- context editing by handling event ⁇ that relate to the standard desktop interface (e.g., scrolling) and feeding module specific events, typically operations in the content area of a window, directly to the creator module of the specified document.
  • the top-level control flow of the ICE kernel which is the primary interface between modules, documents and windows is illustrated in Figure 7 a ⁇ an event loop function.
  • An event loop function is a standard type of function that is written by Macintosh application ⁇ programs to receive events in the event queue from the OS.
  • the particular* event loop function of the ICE kernel is entered at a start state 236 and proceeds to a deci ⁇ ion ⁇ tate 238 to test whether the program ha ⁇ been terminated by the user clicking on the "Quit" operation of the "File” menu. If the program is not done, the kernel moves to a state 240 to wait on the next event by making a call to the Macintosh Operating System (OS) .
  • OS Macintosh Operating System
  • the next event from the event queue could be a "mouse down", i.e., the button of the mouse 118 ( Figure 1) is depres ⁇ ed, "mouse up”, i.e., the mouse button i ⁇ in it ⁇ normal, or relea ⁇ ed, po ⁇ ition, "key down", i.e., a key on the keyboard 120 i ⁇ depressed, and so on.
  • the kernel proceeds to a function 242 to dispatch the event and then return ⁇ to the top of the event loop, state 238 to continue proces ⁇ ing event ⁇ . Assuming that the user quits the program, the event loop moves from state 238 to an end state 244 and returns control to the OS.
  • the di ⁇ patch event function 242 of Figure 7 is preferably implemented by TLocalKernel::DispatchOSEvent which is illustrated diagrammatically in Figure 8.
  • the kernel proceeds to a decision state 250 to test whether the event is a key down, key up or idle event. Idle events are returned by the OS when a request to get an event from the event queue is made and the queue is empty, i.e., no events are pending.
  • a child document or ⁇ ub ⁇ criber document, is a document that is embedded in the parent document, or subscribing document.
  • a child document may be modified by activating a child window which will be further discussed below.
  • the visible regions of child windows must be closed to the OS so that the kernel can 5 intercept, or trap, all clicks in the parent window including those located in child documents.
  • the kernel moves to a state 254 wherein the event is processed according to its type.
  • Figure 9 illustrates the flow diagram for the mouse down event function, called "TLocalKernel: :DoMouseDown", which performs part of the "do" event state 254 of Figure 8.
  • the 15 kernel enters the mouse down function at a start state 258 and then moves to state 260 where it queries whether the clicked pointer 133 ( Figure 2) is in the menu bar 130. If the test is succe ⁇ sful, the kernel proceeds to state 262 wherein it selects the module function of the active window (the module 20 function associated with the clicked menu title) . A test is then made at decision state 264 to determine whether a window handler has been requested due to a mouse down event being received in some portion of a window. If no window handler was selected, as was the case of a menu selection, the kernel 25 . terminates the function at an end state 266.
  • the kernel moves to a decision state 268 and tests whether the click (i.e. , the pointer 133 ( Figure 2) was at a particular location on the screen display provided by the video display 0 124 ( Figure 1) and the mouse button was depressed) was in the system window (not shown) as defined in older Macintosh system ⁇ . If the click i ⁇ in the ⁇ y ⁇ tem window, the system click is handled in state 270, and the kernel terminates the function as previously described through states 264 and 266.
  • the click i.e. , the pointer 133 ( Figure 2) was at a particular location on the screen display provided by the video display 0 124 ( Figure 1) and the mouse button was depressed
  • the kernel moves to a deci ⁇ ion ⁇ tate 272 and tests whether the click was in one of the boxes (i.e., 144, 148, 152, 156 and 158 of Figure 2) and, if so, creates a mouse track event in state 274.
  • the mouse track event is created as a record of mouse position for drag processing.
  • the window handler as ⁇ ociated with the "hit" window (i.e., the window where the click wa ⁇ located) i ⁇ identified at ⁇ tate 276, and after succeeding at the test in state 264, the kernel moves to state 277 and sends the event to the window handler following which the kernel terminates the function at state 266.
  • the kernel moves to a decision ⁇ tate 278 and te ⁇ t ⁇ whether the click wa ⁇ in the content area of the window (e.g., the composition of document areas 192 and 194 in the window 190 of Figure 5) . If the click was in the content area, the window handler associated with the "hit" window is identified at state 280 and the kernel proceeds as described above through the states 264, 277 and 266.
  • the content area of the window e.g., the composition of document areas 192 and 194 in the window 190 of Figure 5
  • the kernel moves to a decision state 282 and tests whether the click was in the desktop (e.g., 138 of Figure 2). If the te ⁇ t i ⁇ ⁇ uccessful, a mouse down event i ⁇ created at ⁇ tate 284 and the kernel terminates the function through the states 264 and 266 as previously discussed. Otherwise, if the click is not in the desktop (the test at state 282), the click is not handled and the kernel terminates the function through the state ⁇ 264 and 266.
  • Figure 10 illu ⁇ trate ⁇ the window handler function TDocumentWindow::DoMou ⁇ eDown which receive ⁇ the mouse down event from TLocalKernal::DoMouseDown at ⁇ tate 277, Figure 9.
  • the kernel moves to a decision state 288 and test ⁇ whether the window i ⁇ active (see, e.g., the inactive and active windows 140, 142 of Figure 2) . If the window is not active, the window is made active at a state 290 by bringing the window to the top, or front, of any other windows and "turning on" the window frame, and then the kernel exits the function at an end state 292.
  • the kernel moves to state 294 and finds the portion of the window (e.g., frame or content portion) that was clicked. If it is determined at decision state 296 that an active (or "live") child document does not exist (the case of Figure 5, i.e., there is no window drawn around the child document, or subscriber document) , the clicked portion of the window is handled at a state 298.
  • the function accomplished in state 298 is more fully described hereafter with respect to Figure 11. From the state 298 the kernel moves to state 292 wherein the function terminate ⁇ .
  • the kernel proceeds to a decision state 300 to determine whether the click was in the active child document. If the click was not in the active child, the kernel moves to a state 302 wherein the parent document, or subscribing document, is identified as the document that is the focus for future clicks. Thereafter, at state 304, the active child's window is closed (i.e., the window frame around the child document will not be displayed at the next refresh of the video display 124 ( Figure 1)) and the parent document is marked active by the kernel so that sub ⁇ equent user event ⁇ (e.g., operations such as "Cut" and "Paste”) may be directed to the parent document.
  • sub ⁇ equent user event ⁇ e.g., operations such as "Cut" and "Paste
  • the kernel terminates the function.
  • the kernel moves to a state 306 wherein the visible region of the child is restricted to be only that portion of the child window (also referred to as a "floater” since child windows do not have ⁇ hadowing a ⁇ in the standard Macintosh window and hence they appear to "float” on the "surface” of a parent window) that intersect ⁇ the parent window.
  • the coordinate system of the visible region is translated from the parent window to -the child window (so that the coordinates, e.g., Cartesian coordinates, of the click correspond to the relative origin specified by the child window handler) and the mouse down event is dispatched to the child window at a state 310.
  • the kernel proceed ⁇ to ⁇ tate 312 to restore the coordinate system back to the parent since the child window proces ⁇ ing i ⁇ complete and the function i ⁇ terminated at end ⁇ tate 292.
  • TDocumentWindow :DoMou ⁇ eDown
  • TDocumentWindow :DoMou ⁇ eDown
  • a test is made on whether the click was on an inactive (or "normal") linked subscription, or subscriber document. (A more detailed di ⁇ cussion of the state 318 will be made hereinbelow with reference to Figure 13.) If not, the function terminates with no action at an end state 320. Otherwise, the kernel moves to a decision ⁇ tate 322 to test whether the child window is being dragged.
  • Thi ⁇ deci ⁇ ion is affirmed if the mouse was moved beyond a preselected distance or if a ⁇ econd click wa ⁇ not received within a pre ⁇ elected time period.
  • the kernel moves to a state 324 and proceeds to move or "drag" the child window.
  • a "drag” re ⁇ ults in a border being drawn around the child and the child window and border being moved with the pointer 200 ( Figure 5) .
  • the kernel then terminates the function at state 320. If it was determined in decision state 322 that no drag occurred, the kernel moves to a decision state 326 to te ⁇ t for a double click. If no double click, i.e., a quick ⁇ uccession of button depre ⁇ sions on the mouse 118 ( Figure 1) , was detected, the kernel proceeds to state 320 to terminate the function.
  • Figure 12 is a screen display that is displayed on the video display 124 ( Figure 1) after the child document, or subscriber document 192, is made active by double clicking on the inactive linked subscription of Figure 5 (no window is open for such a document) , and after a portion of the paint object 193 has been deleted by the user.
  • the tool bar 196 has changed to reflect the operation ⁇ that are made available by the paint program.
  • Al ⁇ o the pointer 200 ha ⁇ changed shape from an "I-beam” pointer to a "pencil” pointer to indicate that paint object ⁇ may now be edited.
  • a child window 334 include ⁇ the window frame that is characteristic of a window displaying a child document.
  • the window frame of the child window 334 is visually different from the window frame of the parent, or sub ⁇ cribing document, window 190 so a ⁇ to provide a visual cue to the user that the editing of the child document 192 will be "in the context of" the parent document 194.
  • the child window 334 is bounded by a dotted line (instead of a solid line) , the title bar i ⁇ ⁇ tippled (instead of containing "racing stripe ⁇ ”) , and there i ⁇ no ⁇ hadowing a ⁇ ⁇ hown around the border of the active window 142 in Figure 2. Thu ⁇ , the user is notified that the documents in the windows 190, 334 in Figure 12 are not completely independent as are the documents in the windows
  • the ICE of the present invention is designed to handle these recursive structure ⁇ and the parent window does not necessarily have to correspond to a standard de ⁇ ktop interface window.
  • Figure 12 Figure 13 diagrammatically illustrates the control flow for "TSubscriptionList::HitTestFloaters” (TSubscriptionList is a subcla ⁇ of TObject) .
  • TSubscriptionList is a subcla ⁇ of TObject.
  • the test for floaters function of Figure 13 correspond ⁇ to the deci ⁇ ion state 318 in Figure 11, i.e., before activating the child window, the ICE must decide which child document was clicked, if any.
  • Figure 13 The function of Figure 13 is entered at a start state 340 and the kernel proceeds to a decision state 342 to test whether there are more embedded (or child) documents in the parent document. Thus, there may be multiple child documents embedded in a parent document and the documents are sequentially searched for a hit until one is found. If there are no more child document ⁇ to proce ⁇ , the kernel terminate ⁇ the function at an end ⁇ tate 344.
  • a document compri ⁇ es one or more pages and the ⁇ ize of a page depend ⁇ on the creator module. For example, the user may have chosen a printer record for the module that defines an 8-1/2" x 11" page ⁇ ize.
  • the vi ⁇ ible pages of the document are those pages that are included by the window (which can be resized at the user's option just a ⁇ in the ⁇ tandard desktop interface) .
  • a child window is "nailed" or assigned to a particular page of the parent document.
  • the kernel proceed ⁇ back to state 342 to get the next embedded document, if one exists. Assuming that there is another visible page to be checked, the kernel move ⁇ from the decision state 346 to a -decision state 348 to test whether the current child document is nailed to a current vi ⁇ ible page of the parent window. If it is not, then the kernel returns to ⁇ tate 346 to ⁇ elect the next visible page. On the other hand, if the test for a current child document being nailed to the current visible page is successful, at state 348, the kernel moves to a decision state 350 to determine whether the child document is in the "live", or active, state. If the child document is live, then the kernel moves to state 352.
  • the next set of processing states relate to the fact that the ICE uses a separate window strategy for child windows than that of the standard desktop interface.
  • the kernel must trap all clicks to the parent window before making them available to the child windows.
  • the trapping mechanism i ⁇ realized by alway ⁇ making the child window not visible to the operating system, and selectively setting the child window to visible once the kernel decides that the child window should receive the click.
  • the vi ⁇ ible region (only the portion of the document that is viewed through the window) of the child document i ⁇ opened.
  • the kernel gets the child's window handler and next, at state 356, the mouse down event is dispatched to the child window via the selected handler to determine what portion of the child window received the click. Once the mouse down event has been handled by the child window handler the visible region of the child document is closed (state 358) .
  • the kernel proceeds to state 360 to calculate the corner coordinates of the contents portion of the inactive window. Now, the kernel moves from either of state ⁇ 358 or 360 to a decision state 362 to decide whether the click occurred in the child document (whether active or inactive) .
  • the kernel proceeds back to state 346 to check for more visible pages.
  • the kernel proceeds to state 366 to create a unique token for the child document.
  • the token is u ⁇ ed internally by the kernel to identify the hit child document.
  • the token i ⁇ not made acce ⁇ ible to a module as, in keeping with the gestalt of the invention, a module need not have knowledge of other documents.
  • the kernel terminates the function at an end state 368.
  • Figure 14 illustrate ⁇ the control flow for the "TSub ⁇ criptionLi ⁇ t: :LaunchPubli ⁇ herFromToken" function which i ⁇ a part of the kernel.
  • Figure 14 which i ⁇ entered at a ⁇ tart ⁇ tate 372, corre ⁇ ponds to the start document state 330 of Figure 11. Proceeding to a deci ⁇ ion state 374, the kernel therein decides whether an intermediate file (for instance, the intermediate file 178 shown in Figure 4) , containing the ⁇ ub ⁇ criber, or child, document (e.g., 179, Figure 4), exi ⁇ ts.
  • an intermediate file for instance, the intermediate file 178 shown in Figure 4
  • child, document e.g., 179, Figure 4
  • the kernel moves to state 376 and cause ⁇ a dialog box, which i ⁇ a feature of the ⁇ tandard de ⁇ ktop interface, to be pre ⁇ ented on the video di ⁇ play 124 to prompt the user for further information of the whereabouts of the intermediate file at state 376.
  • a decision state 378 if the intermediate file still cannot be located, the kernel terminates the function at an end state 380, and the user is not allowed to edit the child document. This situation may occur if the user has previously broken the sub ⁇ cription link by, for example, deleting the intermediate file.
  • the intermediate file will be found and thereafter opened at a state 382.
  • the kernel will move to state 382 and open the intermediate file.
  • the file containing the map object 193 is opened.
  • the module and file references e.g., 182, 184, Figure 4
  • the module that created the child document for instance, the paint program used to create the map object 193 ( Figure 12) is opened at state 386.
  • the window e.g., 334 in Figure 12
  • the child document is opened and the opened document is made available for viewing through the window which is opened at state 390 by the kernel.
  • the publishing document is scrolled by the kernel to the sub ⁇ criber document portion that is embedded in the parent, or subscribing, document. Then, proceeding to state 394 the child document is marked as "live" and the intermediate file is closed at state 396. The intermediate file is closed here so that other window ⁇ may access the same file since the intermediate file may be shared by more than one subscribing document. Lastly, the kernel terminates the function at the end state 380.
  • Figure 15 illustrates the control flow for the "TSubscriptionLi ⁇ t: :DrawFloater ⁇ " function that is a part of the kernel.
  • the function illustrated in Figure 15 i ⁇ executed by the computer 100 ( Figure 1) when the user clicks the mouse 118 and the pointer (e.g., 200, Figure 12) is located at a box or arrow in a scroll bar.
  • the kernel continues to a decision state 402 to decide whether embedded, or child, documents exist in the window that received the click. If no child docu ent ⁇ exist, or the child documents have all been proce ⁇ sed, the kernel terminates the function at an end state 404. Otherwise, the next child document in the list of child documents owned by the window is selected and the kernel moves to a decision state 406.
  • a discu ⁇ sion of proces ⁇ ing i.e., a ⁇ equence of states, similar to the following proces ⁇ ing, that relates to determining the inter ⁇ ection of vi ⁇ ible pages and child pages, was presented above with respect to Figure 13.
  • the kernel tests whether there are more visible pages in the parent window that must be checked to determine whether the hit occurred in a child window. If there are not any more vi ⁇ ible page ⁇ to check, the kernel returns to ⁇ tate 402 to get the next child document. Alternatively, the kernel proceed ⁇ to a decision state 408 to test whether the page as ⁇ ociated with the child document i ⁇ the same as the currently selected visible page of the parent window. If the te ⁇ t is unsuccessful, the kernel returns to the state 406 to select the next visible page.
  • the kernel moves from state 408 to a deci ⁇ ion ⁇ tate 410 to determine whether the child document i ⁇ in the "live" ⁇ tate. If the child document is live, the kernel proceeds to state 412 to move the child window according to the amount of scrolling in the parent window that wa ⁇ triggered by the click in the ⁇ croll bar. Next, at a ⁇ tate 414, the kernel era ⁇ es the region of the parent window behind the child window. Proceeding to a state 416, the kernel calculates the intersection of the parent visible region and the child window, since, for example, if the child window overlap ⁇ the parent window, only a portion of the child window will be drawn.
  • the kernel moves to a state 418 wherein the window frame elements of the child frame (or window) are drawn on the video display 124 ( Figure 1) .
  • the kernel next moves to a state 420 wherein, as a final step in drawing the active child window after a scroll, the content area of the child window is drawn on the video display 124.
  • the kernel moves to a state 422 wherein the child document is drawn inside of the parent window on the video display 124 ( ⁇ tate 422) .
  • the kernel then continues to a decision ⁇ tate 424 and querie ⁇ whether a border ⁇ hould be displayed around the selected child document.
  • a border such as a dashed line, may be drawn around the child document if, for example, the user has chosen a "Show Borders" operation in the "Edit" menu. If the border i ⁇ not required the kernel moves back to the state 406 to check the next visible page for child documents. If it is determined in state 424 that a border is required, the kernel moves to a state 426 and draws a border around the child document. The kernel then returns to the state 406 to check for more visible pages.
  • a screen display illustrates the scrolling aspect of the present invention as performed by the function ⁇ hown in Figure 15.
  • the u ⁇ er has dragged the scroll box 156 down the vertical scroll bar 150 and the child window, or floater 334 has moved in the context of, or along with, the parent window 190.
  • Figure 17 illustrate ⁇ the control flow for the "TDocument::CloseLink" function of the kernel.
  • the function of Figure 17 is executed by the computer 100 ( Figure 1) after the child window is caused to be closed, for example, the user double clicks in the content area of the parent window that is outside of the active child window.
  • the kernel enters the function at a start state 430 and proceeds to a state 432 wherein the active child window is marked as invalid.
  • the kernel initiates an update sequence of the parent window by dispatching an event to the window handler which causes the window to be redrawn.
  • the kernel closes the active child window (e.g. , the window 334 in Figure 12) .
  • the kernel then moves to a state 436 and saves the contents of the child window, which have pos ⁇ ibly been modified as has, for instance, the map object 193 of Figure 12.
  • the contents of the child window are save backed to the intermediate file 178 ( Figure 4) on the hard disk 114 ( Figure 1) .
  • Figure 18 is a screen display illustrating the effect of closing the child window 334 shown in Figure 12.
  • the parent window 190 now displays a composite document comprising the parent document containing text object ⁇ and the child document containing the graphic object 193 which was edited to remove undesired portions.
  • Figures 19 to 29 illustrate the function and re ⁇ ult ⁇ of the frame tool portion of the pre ⁇ ently preferred in-context editor (ICE) of the present invention.
  • the frame tool provides a means for creating a linked, subscriber document of a selected object type while a sub ⁇ cribing (or embedding) document is simultaneou ⁇ ly di ⁇ played.
  • the discussion hereinabove made reference to a second document already in existence prior to it being linked with a fir ⁇ t, displayed document.
  • the following discu ⁇ ion of the frame tool ⁇ how ⁇ that the pre ⁇ ent invention al ⁇ o permits a second or ⁇ ubscriber document to be embedded in the sub ⁇ cribing document at the ⁇ ame time that it is created.
  • the parent window 190 displayed on the video display 124 ( Figure 1) , is shown to contain the text object ⁇ of a ⁇ ample, fir ⁇ t document which may be modified by a word proce ⁇ or program or module.
  • the tool bar 196 include ⁇ word processor specific tool buttons, such as the ⁇ uperscript button indicated at 458, so that the active document in the parent window 190 can be operated on by the user (not shown) .
  • a frame tool button 460 in the tool bar 196 has been clicked using the mouse 118 of Figure 1 thu ⁇ cau ⁇ ing the ICE to enter a frame mode.
  • Figure 20 illustrates another screen display, pre ⁇ ented on the video di ⁇ play 124 ( Figure 1) , that continues the frame tool example initially described with respect to Figure 19.
  • the ICE requests that the user select an object type, or module, using a dialog box 464.
  • the dialog box 464 contains a set of buttons 466 having icons that are indicative of the modules, ⁇ uch a ⁇ word proce ⁇ or, that may be ⁇ elected by the u ⁇ er.
  • the button 466a may be clicked to ⁇ elect the manipulation of number objects by a spreadsheet module.
  • the box 464 only ⁇ hows spreadsheet 466a, database 466b, draw 466c and paint 466d buttons, it will be understood that other object types or modules may be made available to the user.
  • FIG. 21 is a screen display which continues the example of the frame tool from Figure 20 and show ⁇ that two document ⁇ are now simultaneously displayed albeit one document is blank.
  • the parent window 190 now contains the child window 334 and the tool bar 196 comprises a new set of tool buttons which includes tools offered by the draw module, since the active window 334 present ⁇ a second document that specifies draw object ⁇ .
  • a button 472 can be clicked if a new rectangular object is desired to be drawn inside of the second document.
  • Figure 22 illustrates the mouse down handling function TToolbar::DoMouseDown which handles a button, including the frame tool button 460, that was clicked in the tool bar 196 using the physical button on the mouse 118 ( Figure 1) .
  • a clicked button in the tool bar 196 ( Figure 21) will be indicated to the .kernel as a positive te ⁇ t at the decision state 278 indicating that the ICE has localized the click in the content portion of the display.
  • the get window handler state 280 selects the TVisibleThing: :HandleMouseEvent function and ⁇ end ⁇ an event accordingly. Thereafter, the function of Figure 22 is entered after it is determined that the click was inside of the tool bar 196.
  • the kernel move ⁇ to state 482 and retrieves, from the memory 106 ( Figure 1) , the address of the live or active document structure.
  • the kernel proceeds to ⁇ tate 484 to retrieve the list of all active tools and, at ⁇ tate 486, the next (or fir ⁇ t in this instance) tool index in the active tool list is calculated.
  • the tool list of all modules that belong to the ICE will normally include certain common tool ⁇ , e.g., the frame tool ( ⁇ ee Figure 19, button 460), and the module' ⁇ own unique tools, e.g., the ⁇ uperscript tool (see Figure 19, button 458) .
  • the kernel moves to the end state 494 and exits the tool bar handling function.
  • the kernel decides that all active tools have not yet been checked, the kernel continues to decision state 490 to test whether the currently indexed tool has a button that is visible and hit. If the indexed tool has a button that is not visible or not hit, the kernel loops to state 486 to get the next tool index (i.e., increment the index) , otherwise, the selected tool button is handled at state 492 and the function terminate ⁇ at the end ⁇ tate 494.
  • the TLocalKernel cla ⁇ receives the event and enters the handl e create frame function , TLocalKernel: :HandleCreateFrame, shown diagrammatically in Figure 23, at the start state 500.
  • the kernel then moves to a decision state 502 to query whether the ICE is in "frame mode". If not, the kernel proceeds to ⁇ tate 504 to retrieve the addre ⁇ of the live document ⁇ tructure and subscription list. Then, at decision state 506, a test is made for whether the window allows the use of the frame tool.
  • the kernel sets frame mode "on" at state 508 and sets menu and tool bar states so as to highlight the frame tool button, terminating the function at state 512.
  • states 508 and 510 are bypassed and the function terminates at state 512.
  • frame mode is turned “off" at state 514.
  • the kernel moves from state 514 to state 516 to set menu and tool bar states, unhighlighting the frame tool button, and the function terminates as before at state 512.
  • the frame tool button 460 serves to toggle the ICE in and out of frame mode.
  • Figure 24 the mouse down handler function in TFrame i ⁇ entered when the in-context editor (ICE) has frame mode set "on" (see previous Figures 22 and 23) and the user clicks the mouse 118 in the window 190.
  • Figure 24 is an extension of the handler function already described with respect to Figure 11 so as to include the logic to handle the frame mode.
  • the kernel proceeds to decision state 520 in Figure 24 to query whether the ICE i ⁇ in frame mode.
  • the kernel continues as before through Figure 11, beginning at state 318, if the ICE is not in frame mode.
  • the kernel moves to ⁇ tate 522 to track a rectangle. More ⁇ pecifically, the po ⁇ ition at which the ou ⁇ e 118 ( Figure 1) wa ⁇ initially clicked i ⁇ ⁇ tored a ⁇ one corner vertex of a rectangular region within the outlined frame 462 ( Figure 19) . Now, the u ⁇ er moves the mou ⁇ e 118 and the frame 462 contracts and expands since the first clicked corner is now "nailed" to one position on the video di ⁇ play 124. The window 190 may even ⁇ croll if the u ⁇ er move ⁇ the mouse 118 so that the pointer moves into a portion of the document that is not presently displayed.
  • the kernel checks whether the rectangular frame 462 is larger than a minimum size, and if it is not, then frame mode processing is exited to state 320 in Figure 11.
  • the minimum size rectangle is 25 pixel ⁇ by 25 pixel ⁇ .
  • a minimum size is needed for the practical reason of manipulation by a mouse, e.g., inserting window controls ⁇ uch a ⁇ a growth button, and for di ⁇ playing an image that i ⁇ meaningful, i.e., not ⁇ o ⁇ mall that it cannot be read by a human.
  • the kernel creates a document in frame event, at function 526, and send ⁇ the event to the document ( ⁇ tate 528) , e.g., the text document shown in Figure 19, and continues to state 320 in Figure 11.
  • the document e.g., the text document shown in Figure 19, and continues to state 320 in Figure 11.
  • ⁇ ince the present or subscribing document and as ⁇ ociated module e.g., word processor, is known and active, the event is ⁇ ent to itself, and the task of creating a new (e.g., second) document is handled at the appropriate time by the module.
  • the presently preferred function 526 creates a document of a user ⁇ pecified object type, creates and ⁇ ave ⁇ a file, corre ⁇ ponding to the new document, to the hard di ⁇ k 114, tran ⁇ lates the coordinate system of the frame 462 to the upper left corner of the file (or publishing document) , creates and saves an intermediate file to the hard disk 114, creates a link in the subscribing document with the intermediate file, and opens a child window as, for example, indicated at 334 in Figure 21.
  • FIG. 20 is a screen di ⁇ play ⁇ howing an example of the dialog, wherein the dialog box 464 is presented to the user with a list of module (or object) types 466. Then, at decision state 536, a test is made for whether a module was selected and if one was not selected, e.g., the user clicked on the cancel button 469 ( Figure 20) , the function is exited at end state 537.
  • the kernel creates a new document which includes allocating a part of the memory 106 ( Figure 1) for a document structure and opening a new file on the hard disk 114. Proceeding to decision ⁇ tate 540, if the creation was unsucce ⁇ sful, for example, no memory could be allocated, for the document structure the function terminates through end state 537. Otherwi ⁇ e, the file definition structure owned by the document is retrieved from the memory 106 (state 542) and the document and file are saved to the disk 114 (state 544) .
  • the kernel tests whether the file now exist ⁇ on the di ⁇ k 114. If ⁇ o, the kernel move ⁇ to ⁇ tate 548 to tran ⁇ late the coordinate ⁇ y ⁇ te of region in the frame 462 to the coordinate system of the newly created, publishing document. Then, at state 550, the kernel creates an intermediate file 178 ( Figure 4) on the hard di ⁇ k 114. The kernel next moves to state 552 to automatically create a link between the subscribing document, shown for example as text in the parent window 190 of Figure 21, and the subscriber document defined by the intermediate file.
  • the start document function 330 opens a module (e.g., the draw module as shown in Figure 21) , opens a child window (e.g. , the window 334, Figure 21) and open ⁇ the subscriber document structure and file.
  • the framed region is now the frontmost document on the video display 124 ( Figure 1) and is ready to be edited.
  • the kernel moves to state 556 to delete the document structure from the disk 114. Then, at state 558, the document in the parent window 190 is made active and the function is exited at state 537.
  • a click in the parent window 190 out ⁇ ide of the child window 334 (Figure 26) cau ⁇ e ⁇ the child window 334 to not be displayed, and the documents are now viewed in the window 334 as a single, composite document containing text objects and draw objects 562 (although both documents retain their own unique identities in memory) .
  • Figure 28 shows that the child window 334 has been activated by a click, the draw module has been opened, and the user has modified the embedded document by deleting the circle object 563c ( Figure 27) .
  • the present invention includes an in-context editor with a frame tool.
  • the frame tool allows a new document to be created, positioned and object type selected while another document is being actively edited. Indeed, frames can be defined before objects are added, thus providing the equivalent of picture placeholders in a book.
  • the frame tool frees the user from knowledge about the mechanics of linking documents.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Digital Computer Display Output (AREA)

Abstract

Un programme d'édition en contexte comprend un noyau (214) ainsi qu'un ou plusieurs modules (184). Le programme d'édition en contexte comprend un outil d'encadrement utilisé pour créer, positionner et sélectionner dynamiquement selon un type d'objet un document (194), tout en affichant simultanément un autre document (192).
PCT/US1992/006634 1991-08-06 1992-08-06 Systeme d'edition en contexte a outil d'encadrement Ceased WO1993003473A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US74110391A 1991-08-06 1991-08-06
US741,103 1991-08-06
US83990192A 1992-02-21 1992-02-21
US839,901 1992-02-21

Publications (1)

Publication Number Publication Date
WO1993003473A1 true WO1993003473A1 (fr) 1993-02-18

Family

ID=27113812

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1992/006634 Ceased WO1993003473A1 (fr) 1991-08-06 1992-08-06 Systeme d'edition en contexte a outil d'encadrement

Country Status (2)

Country Link
AU (1) AU2494392A (fr)
WO (1) WO1993003473A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0703537A1 (fr) * 1994-09-20 1996-03-27 International Business Machines Corporation Systèmes et procédés pour créer et régénérer des documents composés
GB2315140A (en) * 1996-07-11 1998-01-21 Ibm Multi-layered HTML documents
US7839541B2 (en) * 2004-06-30 2010-11-23 Canon Kabushiki Kaisha Image editing system and method therefor
US9747267B2 (en) 2013-08-12 2017-08-29 Adobe Systems Incorporated Document editing synchronization

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4663615A (en) * 1984-12-26 1987-05-05 International Business Machines Corporation Document creation
US4823303A (en) * 1986-07-17 1989-04-18 Kabushiki Kaisha Toshiba Display control apparatus for use in composite document processing apparatus
US4962475A (en) * 1984-12-26 1990-10-09 International Business Machines Corporation Method for generating a document utilizing a plurality of windows associated with different data objects
US4975690A (en) * 1988-11-07 1990-12-04 Ibm Corporation Method for concurrent data entry and manipulation in multiple applications
US5051930A (en) * 1988-03-16 1991-09-24 Hitachi, Ltd. Method and apparatus for editing documents including a plurality of data of different types

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4663615A (en) * 1984-12-26 1987-05-05 International Business Machines Corporation Document creation
US4962475A (en) * 1984-12-26 1990-10-09 International Business Machines Corporation Method for generating a document utilizing a plurality of windows associated with different data objects
US4823303A (en) * 1986-07-17 1989-04-18 Kabushiki Kaisha Toshiba Display control apparatus for use in composite document processing apparatus
US5051930A (en) * 1988-03-16 1991-09-24 Hitachi, Ltd. Method and apparatus for editing documents including a plurality of data of different types
US4975690A (en) * 1988-11-07 1990-12-04 Ibm Corporation Method for concurrent data entry and manipulation in multiple applications

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0703537A1 (fr) * 1994-09-20 1996-03-27 International Business Machines Corporation Systèmes et procédés pour créer et régénérer des documents composés
US5659676A (en) * 1994-09-20 1997-08-19 International Business Machines Corporation Systems and methods for creating and refreshing compound documents
GB2315140A (en) * 1996-07-11 1998-01-21 Ibm Multi-layered HTML documents
US6065024A (en) * 1996-07-11 2000-05-16 International Business Machines Corporation Embedded HTML documents downloaded and displayed simultaneously with primary HTML document
US7839541B2 (en) * 2004-06-30 2010-11-23 Canon Kabushiki Kaisha Image editing system and method therefor
US9747267B2 (en) 2013-08-12 2017-08-29 Adobe Systems Incorporated Document editing synchronization

Also Published As

Publication number Publication date
AU2494392A (en) 1993-03-02

Similar Documents

Publication Publication Date Title
US5140677A (en) Computer user interface with window title bar mini-icons
US6154756A (en) Computer system integrating different data types into a single environment
US8095867B2 (en) System and computer program product for copying and pasting displayed elements of a range of cells in an electronic spreadsheet
US5467448A (en) Text formatting by the direct selection of borders in an editing display
US7631320B2 (en) Method and apparatus for improved interaction with an application program according to data types and actions performed by the application program
US8230321B2 (en) System in an electronic spreadsheet for displaying and/or hiding range of cells
US5694610A (en) Method and system for editing and formatting data in a dialog window
US5754178A (en) Method and apparatus for improved feedback during manipulation of data on a computer controlled display system
US5544301A (en) Object-oriented view layout system
US5621878A (en) Method and apparatus or manipulating data from a suspended application program on a computer-controlled display system
US5911067A (en) Method and apparatus for improved application program switching on a computer-controlled display system
US5598524A (en) Method and apparatus for improved manipulation of data between an application program and the files system on a computer-controlled display system
US5950216A (en) Method and system for marking and subsequently retrieving a collection of objects within a multipage compound document utilizing selectable page numbered dialog boxes
US6061058A (en) Method and apparatus for transferring data by type according to data types available
US7275207B2 (en) System and method in an electronic spreadsheet for displaying and/or hiding range of cells
EP0622730A2 (fr) Encapsulation en objets d'extraits de documents
US5696915A (en) Method and apparatus for linking routines for different contexts
JP2001216463A (ja) スプレッドシートのセル指定範囲に要素を追加または除去するための方法およびシステム
US7665017B2 (en) Computer system integrating different data types into a single environment
US20030188258A1 (en) System and method in an electronic spreadsheet for displaying and/or hiding range of cells
US5802531A (en) Method and system for embedding parts of documents and synchronizing multiple views thereof
WO1993003473A1 (fr) Systeme d'edition en contexte a outil d'encadrement
JPH0563819B2 (fr)
JPH0289123A (ja) メニュー表示制御方式
Cameron XIB: X-Icon Interface Builder

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BB BG BR CA CS FI HU JP KP KR LK MG MN MW NO PL RO RU SD

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL SE BF BJ CF CG CI CM GA GN ML MR SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
EX32 Extension under rule 32 effected after completion of technical preparation for international publication

Ref country code: UA

LE32 Later election for international application filed prior to expiration of 19th month from priority date or according to rule 32.2 (b)

Ref country code: UA

LE32 Later election for international application filed prior to expiration of 19th month from priority date or according to rule 32.2 (b)

Ref country code: UA

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA