| |
|
|
DATABASE OR FILE ACCESSING |
Method and system for in-place interaction with contained objects5613058
Abstract
A computer method and system for interacting with a containee object contained within a container object. In a preferred embodiment of the present invention, the container object has a container application with a container window environment that has container resources for interacting with the container object. The containee object has a server application with a server window environment with server resources for interacting with the containee object. The method of the present invention displays the container window environment on a display device. A user then selects the containee object. In response to selecting the containee object, the method integrates a plurality of the server resources with the displayed container window environment. When a user then selects a server resource, the method invokes the server application to process the server resource selection. Conversely, when a user selects a container resource, the method invokes the container application to process the container resource selection.
Claims
We claim:
1. A method in a computer system of activating a containee object contained within a container object, the computer system having an operating system fox scheduling execution of code, the container object having container application code with a container window environment with container resources for interacting with the container object, the cornsince object having server application code with server resources for interacting with the containee object, the method comprising the steps of:
executing the container application code as a separately scheduled entity of the operating system;
under control of rite separately executing container application code,
displaying the container window environment; and
displaying the containee object wiflfin the displayed container window enviromnent;
activating the containee object;
integrating and displaying a plurality of the server resources of the server application code with the container resources of the displayed container window enviroment, the server application code being separately schedulable by the operating system;
when a user selects a resource from among the integrated resources, determining whether to invoke the container application code or the server application code; and
when the selected resource is a server resource, executing the server application code as a separately scheduled entity to process the server resource selection.
2. The method of claim 1, the container application code having container menus allocated and managed by the container application code and the server application code having server menus allocated and managed by the server application code, and wherein the step of integrating and displaying a plurality of server resources comprises the substeps of:
generating a composite menu bar; and
storing a server menu and a container menu in the generated composite menu bar.
3. The method of claim 2 wherein the step of storing interleaves server menus and container menus in the composite menu bar.
4. The method of claim 2, the container window having a menu bar for displaying a plurality of menus and wherein the composite menu bar is displayed as the menu bar of the container window.
5. The method of claim 1 wherein the step of activating the containee object further comprises the steps of:
selecting the containee object; and
specifying an operation to be performed on the containee object.
6. A method in a computer system of interacting with a containee object contained within a container object, the computer system having an operating system for scheduling and executing code, the container object having container application code with a container window enviromnent, the containee object having server application code with server resources for interacting with the containee object, the method comprising the steps of:
executing the container application code as a separately scheduled entity of the operating system;
displaying the container window environment, the container window environment having container resources for interacting with the container object;
activating the containee object within the container window environment;
integrating and displaying a plurality of the server resources within the container window environment, the server resources being part of the server application code, the server application code being separately schedulable by the operating system;
in response to selection of a server resource from among the integrated is server resources, invoking the server application code as a separately scheduled entity to process the server resource selection; and
in response to selection of a container resource from the displayed container window environment, invoking the container application code to process the container resource selection.
7. The method of claim 6, the container application code having a window within the displayed container window environment for displaying data and further comprising the step of, under control of the server application code, negotiating with the container application code to place server resources within the window.
8. The method of claim 6 wherein the step of integrating and displaying the plurality of server resources within the container window environment is performed without the container application code knowing, in advance or at the time of displaying, what server resources are to be displayed.
9. The method of claim 6 wherein the container application code and the server application code execute as separate threads in a single computer process.
10. The method of claim 6, further comprising the step of, after integating the plurality of the server resources, displaying the containee object within the container window environment with highlighting to indicate that server resources are available for user selection.
11. The method of claim 6, the container application code having a container message handler for receiving and processing messages and the server application code having a server message handler for receiving and processing messages, the container object having a current message handler for receiving and processing messages, the current message handler initially set to the container message handler, wherein the step of integrating and displaying the plurality of server resources further comprises setting the current message handler of the container object to a special message handler that sends container resource selection messages to the container message handler when a container resource is selected and that sends server resource selection messages to the server message handler when a server resource is selected.
12. The method of claim 6, the container window environment having a window and the server application code having a server window environment with a window, and including the steps of:
designating the server window environment window as having input focus for receiving user input;
receiving a menu command from a user; and
in response to receiving the menu command,
designating the container window environment window as having input focus for receiving user input;
receiving a menu mnemonic; and
in response to receiving the menu nmemonic, redesignating the server window environment window as having input focus for receiving user input.
13. The method of claim 12 where the container window environment window is an application frame window.
14. The method of claim 6, the computer system having a keyboard for inputting keys, the container application code having a plurality of accelerator key combinations for selecting container resources, the server application code having a plurality of accelerator key combinations for selecting server resources, and further comprising the step of, upon the container application code receiving an accelerator key combination, invoking the separately scheduled server application code to determine whether a server resource is selected.
15. A method in a computer system of interacting with a containee object contained within a container object, the computer system having an operating system for scheduling execution of code, the container object having associated container application code with a plurality of container menus, the container application code having an associated menu bar for displaying a list of menus, the containee object having associated server application code with a plurality of server menus, the method comprising the steps of:
generating a composite menu list that includes a container menu and a server menu;
displaying the composite menu list in the menu bar;
in response to selection of a displayed container menu, invoking the container application code as a separately scheduled entity of the operating system to process the selected container menu; and
in response to selection of a displayed server menu, invoking the server application code as a separately scheduled entity of the operating system to process the selected server menu.
16. A method in a computer system for integrating menus from a plurality of applications executed as separately scheduled entities of an operating system, the method comprising the steps of:
executing each of the plurality of applications as a seperately scheduled entity:
specifying a set of menu groups for each executing application, each menu group having a plurality of menu items;
combining the specified menu groups from the plurality of executing applications into a composite menu;
displaying the composite menu on a display device;
selecting a menu item of a menu group of the displayed composite menu; and
invoking the executing application that defines the menu group of the selected menu item.
17. The method of claim 16 wherein the plurality of separately scheduled applications includes a container application and a server application and wherein the step of displaying the composite menu displays the composite menu as a menu of the container application.
18. A computer system for activating a coatsinee object contained within a container object, the computer system having an operating system for scheduling execution of code, the container object having container application code with a container window environment with container resources for interacting with the container object file containce object having server application code with server resources for interacting with the containee object, the system comprising:
means for displaying the container window environment;
means for displaying the containee object within the displayed container window environment;
means for activating the containee object within the displayed container window enviromnent;
means for integrating and displaying a plurality of file server resources with the container resources of the displayed container window environment;
means for determining whether to execute the container application code or the server application code when a resource is selected from among the integrated and displayed server resources; and
means for executing the server application as a separately scheduled entity of the operating system when a server resource is the selected resource, and for processing the server resource selection.
19. The system of claim 18, the container application code having container menus allocated and managed by the container application code and the server application code having server menus allocated and managed by the server application code, and wherein the integrating and displaying means includes means for generating a composite menu bar and storing a server menu and a container menu within the composite menu bar.
20. The system of claim 19 wherein the generating and storing means includes means for interleaving server menus and container menus in the composite menu bar.
21. The method of claim 19 wherein the container window environment has a menu bar that displays a plurality of menus and wherein the composite menu bar is displayed as the menu bar of the container window environment.
22. The system of claim 18 wherein the means for activating selects the containee object and specified an operation to be performed on the containee object.
23. A computer system for interacting with a containee object contained within a container object, the computer system having an operating system for scheduling execution of code, the container object having container application code with a container window environment, the containee object having server application code with server resources for interacting with the containee object, the system comprising:
means for executin the container application code as a separate scheduled entity of the operating system:
means for displaying the container window environment on a display device, the container windown environment having container resources for interacting with the container object;
means for activating the containee object within the displayed container window environment;
means for integrating and displaying a plurality of the server resources of the server application code within the container window enviromnent when the containee object is activated;
means for selecting a server resource from among the integrated and displayed server resources;
means for executing the server application as a separate scheduled entity of the operating system and for invoking the executing server application to process the server resource selection when a server resource is selected;
means for selecting a container resource from among the integrated and displayed server resources; and
means for invoking the executing container application code to process the container resource selection when a container resource is selected.
24. The system of claim 23, the container application code having a window within the container window environment for displaying data and wherein the integrating and displaying means includes means for negotiating with the container application code to place server resources within the window.
25. The system of claim 23, wherein the means for integrating and displaying the plurality of the server resources within the container window environment is accomplished without the container application code knowing, in advance or at the time of displaying, what server resources are to be displayed.
26. The system of claim 23 wherein the container application code and the server application code execute as separate threads in a single computer process.
27. The system of claim 23, further comprising means for displaying the containee object within the container window environment with highlighting to indicate that server resources are available for user selection.
28. The system of claim 23, the computer system including a keyboard for inputting keys, the container application code having a plurality of accelerator key combinations for selecting container resources, the server application code having a plurality of accelerator key combinations for selecting server resources, and including means for invoking the server application code as a separate executed entity to determine if a server resource is selected upon receiving an accelerator key combination.
29. A method in a computer system for activating a containee object contained within a container object, the computer system having an operating system for scheduling execution of code and having a window system for displaying windows and for receiving user input, the computer system having an indicator for choosing an object, the container object having container application code with a container window environment with container resources for interacting with the container object, the containee object having server application code wih server resources for interacting with the containee object, the method comprising the computer-implemented steps of:
to executing the container application code as a separately scheduled entity of the operating system;
displaying fire container window environment;
executing the server application code as a separately scheduled entity of the operating system;
displaying the containee object integrated within the displayed container window environment;
in response to a user mnoving the indicator over the displayed containee object, under control of the window system, generating an input event ands, under control of the window system, sending notification of the input event directly to the executing server application code; and
in response to indicating an action to perform on the containee object, integrating the server resources of axe setvet application code into container resources of the displayed container window environment such that, when a user selects a server resource from amongst the integrated server resources, the executing server application code processes the server resource selection.
30. The method of claim 29, wherein the indicator is controlled by a computer morose, and wherein the step of integrating the server resources of the server application code occurs in response to a mouse button up event.
31. A method in a coinpater system for interacting with a non-native data object, the computer system having an operating system for scheduling execution of code and having a window system for displaying windows and for receiving user input and having an indicator for choosing a data object, the computer system having a container object for containing the non-native data object and for containing a native data object, the container object having container application code with a container window envirnment for interacting with the container object and the native data object, the non-native data object having server application code for interacting with the non-native data object, the method comprising the computer-implemented steps of:
executing the container application code and the server application code as two separately scheduled entities of the operating system;
displaying the container window environment;
displaying the native data object integrated within the displayed is container window environment;
displaying the non-native data object integrated within tile displayed container window environment wherein, from the perspective of a user, initiating interaction with the non-native data object is substantially similar to initiating interaction with the native data object;
in response to the user moving the indicator over the displayed native data object, under control of the window system, generating a first input event and, under control of the window system sending tile first input event directly to the executing nontamer application code; and
in response to the user moving the indicator over the displayed non-native data object, under control of the window system, generating a second input event and, under control of the window system, sending notification of the second input event directly to the executing server application code.
32. The method of claim 30, wherein the server application code has user interface resources for interacting with the non-native data object, and wherein the method further comprises the step of, in response to indicating an action to perform on the non-native data object, integrating the user interface resources of the server application code into the displayed container window environment such that, when a user selects a user interface resource, the scheduled and executing server application code processes the user intexface resource selection.
33. The method of claim 32, wherein the indicator is controlled by a computer mouse, and wherein the step of integrating the user interface resources of the server application code occurs in response to a single mouse click.
34. The method of claim 32, wherein the container application code has user interface resources for interacting with the native data object, and wherein the method further comprises the steps of:
in response to indicating an action to perform on the native data object, removing the integrated user interface resources of the executing server application code from the displayed container window environment; and
after removing the integrated user interface resources of the server application code, displaying the user interface resources of the executing container application code.
35. The method of claim 34, wherein the method further comprises the step of, after displaying the user interface resources of the separately scheduled and executing container application code, in response to indicating an action to perform on the non-native data object, generating a third input event and sending the third input event directly to the separately scheduled and executing server application code.
36. A method in a computer system for interacting with a containee object contained within a container object, the computer system having an operating system for scheduling execution of code and having a window system for displaying windows and for receiving user input and having an indicator for choosing an object, the container object having container application code with a container window environment with container resources for interacting with the container object, the containee object having server application code with server resources for interacting with the containee object, the method comprising the computer-implemented steps of:
executing the container application code as a separately scheduled entity of the operating system;
displaying the container window environment;
executing tim server application code as a separately scheduled entity of the operating system;
displaying the containee object integrated within the displayed container window environment;
in response to a user moving the indicator over the displayed containee object, under control of the window system, generating an input event and, under control of the window system, sending notification of the input event directly to the separately scheduled and executing server application code;
in response to indicating an action to perform on rite containee object, integrating the server resources of the server application code into the container resources of the displayed container window environment, wherein, when a user selects a server resource from amongst the integrated server resources, the separately scheduled and executing server application processes the server resource selection; and
in response to indicating an action to perform on the container object, removing the integrated server resources from being integrated inlo the container resources of the displayed container window environment.
37. A method in a computer system for activating a plurality of containee objects within a container object, the computer system having an operating system for scheduling execution of code and having a window system for displaying windows and for receiving user input, the computer system having an indicator for choosing an object, the container object having container application code with a container window environment for interacting with the container object, each of the phrality of containee objects having server application code for interacting with the containee object, the method comprising the computer-implemented steps of:
executing the container application code as a separately scheduled entity of the operating system;
displaying the container window enviromnent;
displaying a first containee object integrated within the displayed container window environment;
displaying a second containee object within the displayed container window environment;
executing the server application code of the first containee object as a separately scheduled entity;
in response to a user moving the indicator over the displayed first containee object, under control of the window system, generating a first input event and, under control of the windows system, sending notification of the first input event directly to the executing server application code of the first containee object;
executing the server application code of the second containee object as a separately scheduled entity; and
in response to a user moving the indicator over axe displayed second containee object, under control of the window system, generating a second input event and, under control of the window system, sending notification of the second input event directly to the executing server application code of the second containee object.
38. The method of claim 37, wherein each of the plurality of containee objects has user interface resources for interacting with the containee object, and wherein the method further comprises the steps of:
in response to indicating an action to perform on the first eontainee object, integrating the user interface resources of the first containee object into the displayed container window environment;
in response to indicating an action to perform on the second containee object, removing the integrated user interface resources of the first containee object from the displayed container window environment; and
after removing the integrated user interface resources of the first containee object, integrating the user interface resources of the second containee object into the displayed container window environment.
39. The method of claim 38, further comprising the steps of:
after integrating the user interface resources of the first containee object, displaying the integrated user interface resources; and
after integrating the user interface resources of the second containee object, displaying the integrated user interface resources.
40. A method in a computer system for activating an inside-out activation style containee object within a container object, the container object having container application code that manages a container window environment with container resources, the inside-out activation style containee object having an inside-out window for receiving user input-and having server application code for interacting with the containee object, the server application code having user interface resources for interacting with the containee object, the computer system having an indicator for choosing an object, having an operating system for scheduling execution of code, and having a window system for displaying windows and for receiving user input, the method comprising the computer-implemented steps of:
executing the container application code as a separate executable entity of the operating system;
displaying the container window environment;
displaying the inside-out activation style containee object integrated within the container window enviromnent, wherein the inside-out window is displayed;
in response to a user moving the indicator over the displayed inside-out window, cxecutixtg the server application code as a separate executable entity of the operating system and, under control of the window system, generating an input event and sending notification of the input event directly to the separately executing server application code;
in response to selecting the displayed inside-out window, integrating the user interface resources of the server application code into the container resources of the container window environment; and
in response to selecting a user interface resource of the server application code from amongst the integrated user interface resources, under control of the separately executing the server application code processing the selected user interface resource.
41. A method in a computer system for activating an inside-out activation style containee object and an outside-in activation style containee object within a container object, the container object having a container window environment, the inside-out activation style containce objcct having an inside-out window for receiving user input and having corresponding server application code for interacting with the containee object, the outside-in activation style containee object having an outside-in window for receiving user input and having corresponding server application code for interacting with the containce object, each server application code having user interface resources for interacting with the corresponding containee object, the cornpurer system having an indicator for choosing an object, having an operating system for scheduling execution of code, and having a window system for displaying windows and for receiving user input, the method comprising the computer-implemented steps of:
executing the container application code as a separate executable entity of the operating system;
displaying the container window environment;
displaying the inside-out activation style containee object integrated within the container window environment, wherein the inside-out window is displayed;
displaying the outside-in activation sWle containee object integrated within the container window environment without displaying the outside-in window;
upon selection of the outside-in activation style containee object, displaying the outside-in window;
executing the server application code of the outside-in activation style containee object as a separate executable entity of the operating system;
executing the server application code of the inside-out activation style containee object as a separate executable entity of the operating system;
in response to a user moving the indicator over the displayed outside-in window, under control of the window system, generating a first input event and sending notification of the first input event directly to the separately executing server application code corresponding to the outside-in activation style containee object; and
in response to a user moving the indicator over the displayed inside-out window, under control of the window system, generating a second input event and sending notification of the second input event directly to the separately executing server application code corresponding to the inside-out activation style containee object.
42. The method of claim 41, the method further comprising the step of, after displaying the outside-in window, upon selection of an object other than the outside-in activation style containee object, removing the outside-in window from the display.
43. A computer system for activating a containee object contained within a container object, the container object having container application code with a container window for interacting with the container object, the containee object having server application code with user interface resources for interacting with the containee object, the computer system comprising:
an indicator for choosing an object;
an operating systems for starting execution of the container application code as a separately schedduled entity and for starting execution of the server application code as a separately scheduled entity;
a window system that displays axe container window environment and that displays the eontainee object integrated within the displayed container window environment;
an input event generating mid handling mechanism, flint in response to moving the indicator over the displayed containee object, generates an input event, directs the operating system to start execution of the container application code and the server application code, and sends notification of the input event directly to the executing server application code; and
a resource integration mechanism, that in response to indicating an action to perform on the coatsince object, integrates the user interface resources of the server application code into the displayed container window environment such that, when a user selects a user interface resource from amongst the integrarod user interface resource, the separately scheduled and executing server application code processes the user interface resource selection.
44. The computer system of claim 43, wherein the indicator is controlled by a computer mouse, and wherein the resource integration mechanism is responsive to a mouse button up event.
45. A computer system for interacting with a non-native data object and a native data object, the non-native data object having server application code for interacting with the non-native data object, the computer system comprising:
a container object that contains the non-native data object and contains the native data object, the eontainer object having container application code with a container window environment for interacting with the container object and the native data object;
an indicator for choosing an object;
an operating system for starting execution of the container application code and the server application code as separate executable entities, each separate executable entity being a process or a thread;
a window system that displays the container window environment, that displays the native data object integrated within the displayed container window environment, and that displays file non-native data object integrated within the displayed container window environment such that, from the perspective of a user, initiating interaction with the non-native data object is substantially similar to initiating interaction with the nativc data object even though the native data object and the non-native data object are managed by two separately executing application code entities;
an input event generating and handling mechtanism, that in response to moving the indicator over the displayed native data object, generates a first input event and sends notification of the first input event directly to the separately executing container application code; and
an input event generating and handling mechanism, that in response to moving the indicator over the displayed non-native data object generates a second input event and sends notification of the second input event directly to the separately executing server application code.
46. The computer system of claim 45, wherein the server application code has user interface resources for interacting with the non-native data object, the system further including a resource integration mechanism, that in response to indicating an action to perform on the containee object, integrates the user interface resources of the server application code, into the displayed container window environment such that when a user selects a user interface resource from amongst the integrated user interface resources, the separately executing server application code processes the user interface resource selection.
47. A method in a computer system of activating a containee object contained within a container object, the container object having a container application with a container window environment, the container window environment having container resources for interacting with the container object, the containee object having a server application with server resources for interacting with the containee object, the method comprising the steps of:
executing the container application as a separate executable entity of an operating system;
under control of the container application,
displaying the container window environment;
displaying the containee object integrated within the displayed container window environment;
selecting the containee object; and
in response to selecting the containee object, executing the server application as a separate executable entity of the operating system;
under control of the separately executing server application,
indicating the server resources to the container application;
under control of the container application,
integrating the indicated server resources within the displayed container window environment; and
in response to selection of a server resource front the integrated server resources, sending to the separately executing server application all indication that the server resource is selected; and
under control of the server application, performing a behavior associated with the selected server resource.
48. A method in a computer system of activating a containee object contained witfin a container object, the computer system having an operating system for scheduling and executing code, the container object having container application code implemented as a separately schedulable and executable application program and having a container window environment with container resources, the containee object having associated server application code implemented as a loadable code module which is loadable into a memory address space of a separately schedulable and executable application program, the server application code having server resources for interacting with the containee object, the containee object having a class identifier for identifying tile server application code, the method comprising the computer implemented steps of:
executing the container application code as a separately scheduled program with a memory address space;
displaying the container window enviromnent;
displaying the containee object integrated within the displayed container window enviromnent;
selecting the containee object;
in response to selection of the containee object,
determining the class identifier of the containee object;
based upon the determined class identifier, determining from a persistent registry the associated server application code;
loading the determined server application code into the memory address space of the container application code;
under control of the loaded server application code, determining a plurality of server resources; and
integrating and displaying the plurality of the server resources of the loaded server application code into the container resources of the displayed container window environment, without the container application code knowing what server resources are being integrated and displayed; and
in response to selection of a scarer resource from among the integrated and displayed server resources, executing the server application code to process the server resource selection.
Description
TECHNICAL FIELD
This invention relates generally to a computer method and system for interacting with linked and embedded objects and, more specifically, to a method and system for editing and otherwise interacting with a contained object within the context of its container application.
BACKGROUND OF THE INVENTION
Current document processing computer systems allow a user to prepare compound documents. A compound document is a document that contains information in various formats. For example, a compound document may contain data in text format, chart format, numerical format, etc. FIG. 1 is an example of a compound document. In this example, the compound document 101 is generated as a report for a certain manufacturing project. The compound document 101 contains scheduling data 102, which is presented in chart format; budgeting data 103, which is presented in spreadsheet format; and explanatory data 104, which is presented in text format. In typical prior systems, a user generates the scheduling data 102 using a project management computer program and the budgeting data 103 using a spreadsheet computer program. After this data has been generated, the user creates the compound document 101, enters the explanatory data 104, and incorporates the scheduling data 102 and budgeting data 103 using a word processing computer program.
FIG. 2 shows how the scheduling data, budgeting data, and explanatory data can be incorporated into the compound document. The user generates scheduling data using the project management program 201 and then stores the data in the clipboard 203. The user generates budgeting data using the spreadsheet program 204 and then stores the data in the clipboard 203. The clipboard 203 is an area of storage (disk or memory) that is typically accessible by any program. The project management program 201 and the spreadsheet program 204 typically store the data into the clipboard in a presentation format. A presentation format is a format in which the data is easily displayed on an output device. For example, the presentation format may be a bitmap that can be displayed with a standard bitmap block transfer operation (BitBit). The storing of data into a clipboard is referred to as "copying" to the clipboard.
After data has been copied to the clipboard 203, the user starts up the word processing program 206 to create the compound document 101. The user enters the explanatory data 104 and specifies the locations in the compound document 101 to which the scheduling data and budgeting data that are in the clipboard 203 are to be copied. The copying of data from a clipboard to a document is referred to as "pasting" from the clipboard. The word processing program 206 then copies the scheduling data 102 and the budgeting data 103 from the clipboard 203 into the compound document 101 at the specified locations. Data that is copied from the clipboard into a compound document is referred to as "embedded" data. The word processing program 206 treats the embedded data as simple bitmaps that it displays with a BitBlt operation when rendering the compound document 101 on an output device. In some prior systems, a clipboard may only be able to store data for one copy command at a time. In such a system, the scheduling data can be copied to the clipboard and then pasted into the compound document. Then, the budgeting data can be copied to the clipboard and then pasted into the compound document.
Since word processors typically process only text data, users of the word processing program can move or delete embedded data, but cannot modify embedded data, unless the data is in text format. Thus, if a user wants to modify, for example, the budgeting data 103 that is in the compound document 101, the user starts the spreadsheet program 204, loads in the budgeting data 103 from a file, makes the modifications, copies the modifications to the clipboard 203, starts the word processing program 206, loads in the compound document 101, and pastes the modified clipboard data into the compound document 101. The spreadsheet program "implements" the spreadsheet data, that is, the spreadsheet program can be used to manipulate data that is in spreadsheet format. The format that a program implements is referred to as native format.
Some prior systems store links to the data to be included in the compound document rather than actually embedding the data. When a word processing program pastes the data from a clipboard into a compound document, a link is stored in the compound document. The link points to the data (typically residing in a file) to be included. These prior systems typically provide links to data in a format that the word processing program recognizes or treats as a presentation format. For example, when the word processing program 206 is directed by the user to paste the scheduling data and budgeting data into the compound document by linking, rather than embedding, the names of files in which the scheduling data and budgeting data reside in presentation format are inserted into the document. Several compound documents can contain links to the same data to allow one copy of the data to be shared by several compound documents.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and system for interacting with a contained object within a window environment of a container application of a container object.
It is another object of the present invention to provide a method and system for combining menus of the container application with menus of a server application of the contained object.
These and other objects, which will become apparent as the invention is more fully described below, are provided by a computer method and system for interacting with a containee object contained within a container object. In a preferred embodiment, the container object has a container application with a container window environment that has container resources for interacting with the container object. The containee object has a server application with a server window environment with server resources for interacting with the containee object. The method of the present invention displays the container window environment on a display device. A user then activating the containee object. In response to activating the containee object, the method integrates a plurality of the server resources with the displayed container window environment. When a user then selects a server resource, the method invokes the server application to process the server resource selection. Conversely, when a user selects a container resource, the method invokes the container application to process the container resource selection.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an example of a compound document.
FIG. 2 is a diagram showing how the scheduling data, budgeting data, and explanatory data can be incorporated into the compound document.
FIG. 3 is a diagram of the sample compound document shown in FIG. 1 as it appears when edited within the word processing application before in-place interaction occurs.
FIG. 4 is a diagram of the embedded spreadsheet object as it appears when activated in place within the compound document.
FIG. 5 is a diagram which shows the relationship between an object handler and the container and server processes.
FIG. 6 is a block diagram of a sample instance of a linked or embedded object.
FIG. 7 is a block diagram showing a public view of an object.
FIG. 8 is a sample user menu provided by a container application to display and select the actions available for an object.
FIG. 9 is a diagram showing the composite menu bar resulting from the merger of the server application menus with the container application menus of the example shown in FIG. 4.
FIG. 10 is a diagram of the menu groups that compose a composite menu bar in a preferred embodiment of the present invention.
FIG. 11 is a diagram showing the component windows of a typical Single Document Interface application.
FIG. 12 is a diagram showing the component windows of an Multiple Document Interface application.
FIG. 13 is a block diagram showing the typical window hierarchy of a container application when it is editing an embedded object in place.
FIG. 14 is a flow diagram showing message processing in an event-driven windowing operating system environment.
FIG. 14B is a block diagram showing the public interfaces required to support in place interaction.
FIG. 15 is a flow diagram of an implementation of the IOLEInPlaceFrame::SetMenu method.
FIG. 16 is a flow diagram of an implementation of the IOLEInPlaceFrame::EnableModeless method.
FIG. 17 is a flow diagram of an implementation of the IOLEInPlaceParent::OnInPlaceActivate method.
FIG. 18 is a flow diagram of an implementation of the IOLEInPlaceParent::OnUIActivate method.
FIG. 19 is a flow diagram of an implementation of the IOLEInPlaceParent::OnUIDeactivate method.
FIG. 20 is a flow diagram of an implementation of the IOLEInPlaceObject::InPlaceDeactivate method.
FIG. 21 is a flow diagram of an implementation of the IOLEInPlaceObject::InPlaceUIDeactivate method.
FIG. 22 is a flow diagram of an implementation of the IOLEInPlaceObject::Activate method.
FIG. 23 is a flow diagram of an implementation of the ActivateUI function.
FIG. 24 is a flow diagram of an implementation of the CreateObjectToolbars function.
FIG. 25 is a block diagram of the shared menu data structure corresponding to the example discussed in FIG. 4.
FIG. 26 is a flow diagram of an implementation of the ObjectSetMenu function.
FIG. 27 is a flow diagram of an implementation of the function Process.sub.-- Object.sub.-- Activation.
FIG. 28 is a flow diagram of an implementation of the object linking and embedding API function ObjectLoad.
FIGS. 29A and 29B are flow diagrams of an implementation of the IOLEObject::DoVerb method. This method is the primary method for interacting with a containee object.
FIG. 30 is a flow diagram of an implementation of the function Process.sub.-- Activation.sub.-- Message called by the window procedure of an MDI document window to process activation and deactivation messages.
FIG. 31 is a flow diagram of an implementation of the Process.sub.-- Mouse.sub.-- LButtonUp function.
FIG. 32 is an example application that uses a forms architecture as the basis for its user interface.
FIG. 33 is a block diagram of the activation states available for a container object.
FIG. 34 is a flow diagram of the message processing of a typical window procedure of a container application implementing a container object that can activate outside-in objects.
FIG. 35 is a flow diagram of a window procedure for an inside-out containee object implemented by a server application.
FIG. 36 is a block diagram showing the arrangement of objects in a containment hierarchy and typical relationships between their interfaces.
FIG. 37 is a flow diagram of a typical implementation of the IOLEInPlaceUIWindow::SetActiveObj ect method.
FIG. 38 is a flow diagram of a typical implementation of the IOLEInPlaceFrame::SetMenu method for a server application that does not wish to participate in menu merging.
FIG. 39 is a flow diagram of a typical implementation of the IOLEInPlaceParent::OnInPlaceActivate method.
FIG. 40 is a flow diagram of a typical implementation of the IOLEInPlaceParent::OnUIActivate method.
FIG. 41 is a flow diagram of a typical implementation of the IOLEInPlaceParent::OnUIDeactivate method.
FIG. 42 is a flow diagram of a typical implementation of the IOLEInPlaceParent::OnDeactivate method.
FIG. 43 is a flow diagram of a typical implementation of the IOLEInPlaceObject::InPlaceDeactivate method.
FIG. 44 is a flow diagram of a typical implementation of the DeactivateUI function implemented by a server application.
FIG. 45 is a flow diagram of a typical implementation of the UIDeactivateContainedObject function implemented by a server application.
FIG. 46 is a flow diagram of a typical implementation of the DoInPlaceHide function implemented by a server application.
FIG. 47 is a flow diagram of a typical implementation of the InPlaceDeactivateContainedObjects function implemented by a server application.
FIG. 48 is a flow diagram of a typical implementation of the IOLEInPlaceObject::UIDeactivate method.
FIG. 49 is a flow diagram of a typical implementation of the IOLEInPlaceActiveObject::Activate method.
FIG. 50 is a flow diagram of a typical implementation of the ActivateUI function implemented by a server application.
FIGS. 51A abd 51B are flow diagrams of a typical implementation of the DoInPlaceActivate function implemented by a server application.
FIG. 52 is a flow diagram of a typical implementation of the Process.sub.-- Object.sub.-- Activation function implemented by a container application.
FIGS. 53A and 53B are flow diagrams of a typical implementation of the IOLEObject::DoVerb method implemented by a server application.
FIG. 54 is a flow diagram of a typical implementation of the Process.sub.-- Activation.sub.-- Message function invoked by the window procedure of an MDI document window to process MDI activation and deactivation messages.
FIG. 55 is a flow diagram of a typical implementation of the Process.sub.-- Mouse.sub.-- LButtonDown function implemented by a container application.
FIG. 56 is a flow diagram of a typical implementation of the IOLEObject::Close method implemented by a server application.
DETAILED DESCRIPTION OF THE INVENTION
Table of Contents
1. Overview
2. In-Place Interaction Overview
3. Window Support for In-Place Interaction
4. In-Place Interaction API
4.1 IOLEWindow Interface
4.1.1 IOLEWindow::GetWindow
4.2 IOLEInPlaceUIWindow Interface
4.2.1 IOLEInPlaceUIWindow::GetBorder
4.2.2 IOLEInPlaceUIWindow::QueryBorderSpace
4.2.3 IOLEInPlaceUIWindow::SetBorderSpace
4.3 IOLEInPlaceFrame Interface
4.3.1 IOLEInPlaceFrame::SetMenu
4.3.2 IOLEInPlaceFrames:: InsertMenus
4.3.3 IOLEInPlaceFrame::RemoveMenus
4.3.4 IOLEInPlaceFrame:: SetStatusText
4.3.5 IOLEInPlaceFrame::EnableModeless
4.3.6 IOLEInPlaceFrame::TranslateAccelerator
4.4 IOLEInPlaceParent Interface
4.4.1 IOLEInPlaceParent::CanInPlaceDeactivate
4.4.2 IOLEInPlaceParent::OnInPlaceActivate
4.4.3 IOLEInPlaceParent::OnUIActivate
4.4.4 IOLEInPlaceParent::OnUIDeactivate
4.4.5 IOLEInPlaceParent::OnDeactivate
4.4.6 IOLEInPlaceParent::ShadeBorder
4.4.7 IOLEInPlaceParent::GetWindowContext
4.5 IOLEInPlaceObject Interface
4.5.1 IOLEInPlaceObject::InPlaceDeactivate
4.5.2 IOLEInPlaceObject::InPlaceUIDeactivate
4.5.3 IOLEInPlaceObject::TranslateAccelerator
4.5.4 IOLEInPlaceObject::Activate
4.5.5 IOLEInPlaceObject::ResizeBorder
4.5.6 IOLEInPlaceObject::EnableModeless
4.5.7 IOLEInPlaceObject::SetVisRect
4.6 Other Server Application Functions
4.6.1 ActivateUI
4.6.2 CreateNewMenu
4.6.3 CreateObject Toolbars
4.6.4 RemoveMenus
4.7 Object Linking and Embedding API Helper Functions
4.7.1 SetActiveObjectHwnd
4.7.2 GetActiveObjectHwnd
4.7.3ObjectCreateSharedMenu
4.7.4 ObjectDestroySharedMenu
4.7.5 ObjectShade
4.7.6 ObjectSetMenu
5. Use of In-Place Interaction API
5.1 Procedure for Activation in Place
5.1.1 Activation In Place Within a Multiple Document Interface Application
5.2 User Selection of Pulldown Menus Message Handling
5.3 In-Place Deactivation Procedure
5.4 Closing the Container Application
5.5 Interacting with Modeless Dialogs
5.6 Handling Accelerator Key Combinations
6.0 Alternative Embodiment for In-Place Interaction
6.1 Activation Model Support
6.2 Windows Support for the Inside-Out Activation Model
6.3 In-Place Interaction API Support for Inside-Out Activation
6.3.1 IOLEWindow Interface
6.3.2 IOLEInPlaceUIWindow Interface
6.3.2.1 IOLEInPlaceUIWindow::SetActiveObject
6.3.3 IOLEInPlaceFrame Interface
6.3.3.1 IOLEInPlaceFrame::SetMenu
6.3.4 IOLEInPlaceParent Interface
6.3.4.1 IOLEParent::OnInPlaceActivate
6.3.4.2 IOLEInPlaceParent::OnUIActivate
6.3.4.3 IOLEInPlaceParent::OnUIDeactivate
6.3.4.4 IOLEInPlaceParent::OnDeactivate
6.3.4.5 IOLEInPlaceParent::GetWindowContext
6.3.4.6 IOLEInPlaceParent::Scroll
6.3.4.7 IOLEInPlaceParent::OnPosRectChanged
6.3.5 IOLEInPlaceObject Interface
6.3.5.1 IOLEInPlaceObject::InPlaceDeactivate
6.3.5.2 Server Application Function - DeactivateUI
6.3.5.3 Server Application- UIDeactivateContainedObject
6.3.5.4 Server Application- DoInPlaceHide
6.3.5.5 Server Application- InPlaceDeactivateContainedObjects
6.3.5.6 IOLEInPlaceObject::UIDeactivate
6.3.5.7 IOLEInPlaceObject::SetVisRects
6.3.6 IOLEInPlaceActiveObject Interface
6.3.6.1 IOLEInPlaceActiveObject::Activate
6.3.6.2 IOLEInPlaceActiveObject::ResizeBorder
6.3.6.3 Server Application- ActivateUI
6.3.7 Object Linking and Embedding Facilities Helper Functions
6.4 Use of In-Place Interaction API With Inside-Out Objects
6.4.1 Determining the Activation Model of Objects
6.4.2 Activating Objects
6.4.2.1 Activating Inside-Out Objects Within a Multiple Document Interface Application
6.4.3 Deactivating Objects
6.4.4 Closing the Container Application
1. Overview
The present invention provides a generalized method, referred to as in-place interaction, for interacting with embedded or linked data in the context of a compound document. That is, the application to be used to interact with the embedded or linked data is made accessible to the user through the window environment (for example menus and windows) of the application that implements the compound document. This accessibility is referred to as activation in place. In a preferred embodiment, when embedded or linked (contained) data is activated in place, the menus of the application that implements the contained data are merged with the menus of the application that implements the compound document to create a composite menu bar. The order of the menus in the composite menu bar is determined by a set of menu groups. Each application categorizes its menus into these menu groups and places its menus in the composite menu bar in the order of the menu groups. The composite menu bar is then installed as the menu bar of the application implementing the compound document, and a message handler is installed to filter messages sent to the windows of this application. When the user selects a menu item, the message handler determines whether the menu item belongs to a menu of the application implementing the contained data or the application implementing the compound document. The message handler then sends the input message corresponding to the selected menu item to the correct application.
The present invention defines a set of abstract classes (interfaces) and thnctions through which contained data is activated in place. (In the C++ programming language, an abstract class is a class with a definition of its data and methods, but with no implementation for those methods. It is the responsibility of the application implementing the class to provide the actual code for the methods available to manipulate the class instance data.) The application implementing the compound document is responsible for implementing some of these interfaces and the application implementing the contained data is responsible for implementing others.
In a preferred embodiment of the present invention, an application program that creates a compound document controls the manipulation of linked or embedded data generated by another application. In object-oriented parlance, this data is referred to as an object. (The reference Budd, T., "An Introduction to ObjectOriented Programming," Addison-Wesley Publishing Co., Inc., 1991, provides an introduction to object-oriented concepts and terminology.) An object that is either linked or embedded into a compound document is "contained" within the document. Also, a compound document is referred to as a "container" object and the objects contained within a compound document are referred to as "contained" or "containee" objects. Referring to FIGS. 1 and 2, the scheduling data 102 and budgeting data 103 are containee objects and the compound document 101 is a container object. The user can indicate to the word processor that the user wants to edit a containee object, such as the budgeting data 103. When the user indicates that the budgeting data 103 is to be edited, the word processing program determines which application should be used to edit the budgeting data (e.g., the spreadsheet program) and launches (starts up) that application. The user can then manipulate the budgeting data using the launched application, and changes are reflected in the compound document. The same procedure is used. whether the budgeting data is stored as an embedded or linked object.
If the application used to edit the budgeting data supports in-place interaction, then, when it is launched by the word processing program, it is activated within the window environment of the word processing program. FIGS. 3 and 4 illustrate the process of activating the embedded budgeting data 103 in place.
FIG. 3 is a diagram of the sample compound document shown in FIG. 1 as it appears when edited within the word processing application before in-place interaction occurs. The main window of the container application 301 contains a title bar 302, a menu bar 303, and a client window 304. The client window 304 displays the manufacturing project report discussed in FIG. 1. The compound document contains an embedded spreadsheet object (the budgeting data 305). When the user edits the native text data of the compound document, the menu bar 303 appears as shown: it includes all of the commands necessary to interact with the word processing application.
When the user decides to edit the budgeting data 305, the user selects the spreadsheet object 305 and requests the word processing application to edit the object (e.g., by double clicking on the object using the mouse). The word processing application then launches the spreadsheet application requesting that it edit the spreadsheet object 305. The spreadsheet application negotiates with the word processing application to edit the spreadsheet object 305 using windows 301 and 304 and the menu bar 303 of the word processing application.
FIG. 4 is a diagram of the embedded spreadsheet object as it appears when activated in place within the compound document. The spreadsheet object 405 is edited directly in the client window 404 of the word processing application. The title bar 402 is changed to reflect that the application implementing the compound document, in this case a word processing application, is editing a spreadsheet worksheet within the compound document "VAC1.DOC." Also, the menu bar 403 is changed to a new composite menu bar, which comprises menus from the word processing application and menus from the spreadsheet application. In addition, various aspects of the embedded spreadsheet object 405 are changed to reflect that it is being edited within its container compound document. A selection highlight 406 in the form of a hatched border pattern is placed around the object. Also, the standard tools of the spreadsheet application, in this case the row and column markers 407, are placed around the spreadsheet object. Also, the spreadsheet selection cursor 408 is placed around the currently selected cell. At this point, the user is ready to edit the spreadsheet object 405 using all of the spreadsheet application commands.
In a preferred embodiment, application programs ("applications") cooperate using object linking and embedding facilities to create and manipulate compound documents. An application that creates a compound document is referred to as a container (or client) application, and an application that creates and manipulates containee objects is referred to as a server application. An application can behave as both a container and server. That is, an application can contain objects and the objects that the application implements can be contained within other objects. Referring to FIG. 2, the project management program 201 and the spreadsheet program 204 are server applications, and the word processing program 206 is a container application. A container application is responsible for selection of the various objects within the container object and for invoking the proper server applications to manipulate the containee objects. Server applications are responsible for manipulating the contents of the containee objects.
In a preferred embodiment, applications are provided with an implementation-independent Application Programming Interface (API) that provides object linking and embedding functionality. The API is a set of functions that are invoked by container and server applications. These functions manage, among other things, the setup and initialization necessary for container applications to send and receive messages and data to and from server applications. The API provides functions to invoke server applications to manipulate containee objects.
The invoking of a server application can be relatively slow when the server application executes as a separate process from the container application. In certain situations this slowness may be particularly undesirable. For example, if a user wants to print a compound document that includes many containee objects, it may take an unacceptably long time to invoke the server process for each containee object and request each server process to print the object. To ameliorate this unacceptable performance, a server application can provide code that can be dynamically linked during runtime into the process of the container application to provide certain functionality more efficiently. This code is called an "object handler." Object handlers provide functionality on behalf of the server application so that the object linking and embedding API can avoid starting up server processes and passing messages to the server process. In the above example, an object handler could provide a print function that the object linking and embedding API could invoke to print a containee object.
FIG. 5 is a diagram which shows the relationship between an object handler and the container and server processes. The object handler 502 is linked into the container process address space 501 during runtime by the object linking and embedding API 503. Typically, the object linking and embedding API 503 invokes the object handler 502 directly, and the container application code need not be aware that a handler is providing the functionality, rather than a server process 507.
In addition to providing a set of functions, the object linking and embedding ("OLE") API defines "interfaces" through which container applications can communicate with their contained objects. An interface is a set of methods (in C++ parlance) which abide by certain input, output, and behavior rules. If a contained object supports (provides an instrumentation for) a particular interface, the container application can invoke the methods of that interface to effect the defined behavior. In a preferred embodiment, the container application does not directly access the object data. Rather, it preferably accesses the object data using the supported interfaces. A container application is bound to a contained object through a pointer to an interface instance. The container application accesses the object data by invoking the methods of the interface instance. To access the object data, the methods may send messages to the server application requesting the specified access. In a preferred embodiment, messages are sent between container and server applications when the server application is implemented as a separate process using interprocess communications mechanisms provided by the underlying operating system.
FIG. 6 is a block diagram of a sample instance of a linked or embedded object. In a preferred embodiment, the layout of the instance conforms to the model defined in U.S. Pat. No. 5,297,284, entitled "A Method for Implementing Virtual Functions and Virtual Bases in a Compiler for an Object Oriented Programming Language" which is hereby incorporated by reference. The instance contains object data structure 601 and interface data structure 613 for each supported interface. The object data structure 601 contains pointers 602 to the interface data structures 613 and may contain private data of the instance. The private data of this sample instance includes a class identifier 603, handle 604 to the storage for the object, and data 605 for tracking the state of the object. The class identifier (CLASS.sub.-- ID) is used to access the appropriate server application for the object. It is similar to a data structure "type" used in programming languages. A method can determine this server application for the object by using its CLASS.sub.-- ID as an index into a persistent global registry. The persistent global registry is discussed further below. As shown in FIG. 6, each interface data structure 613 contains a private data structure 606 and a virtual function table 608. The private data structure 606 contains a pointer 607 to the virtual function table 608. The virtual function table 608 contains pointers 609 and 611 to the code 610, 612 that implements the methods of the interface.
TABLE 1
______________________________________
# define interface class
interface intf {public:
virtual RETCODE fnc.sub.1 (arg1, arg2) = 0;
virtual RETCODE fnc.sub.2 (arg1, arg2) = 0;
virtual RETCODE fnc.sub.3 ( ) = 0;
. . .
};
______________________________________
Table 1 represents the definition for the interface for the first entry pintf.sub.1 in the object data structure 601. In Table 1, the word "interface" is defined to mean a C++ class. The definition shows three methods with their parameters. The word "virtual" indicates that the declared method can be overridden by a method of the same name and type in a derived class. (A derived class is a class that inherits the data members and methods of its base class.) The "=0" at the end of each parameter list indicates that the method has no code implementation. In the C++ programming language, these methods are termed "pure virtual functions". In C++ a class with at least one pure virtual function is referred to as an abstract class. In a preferred embodiment, an interface is an abstract class with no data members and whose virtual functions are all pure. Thus, an interface provides a protocol for two programs to communicate. To support an interface, a program implements a class that provides an implementation for the interface (through derivation). Thereafter, objects are created as instances of this class.
FIG. 7 is a block diagram showing a public view of an object. The public view of an object is the various interfaces that the object supports 702-706. Each interface provides methods through which container applications can access the object. Each object supports an IUnknown interface 702. Container applications use the IUnknown interface 702 to determine which other interfaces the object supports. The implementation of IUnknown interface 702 for a particular object knows what other interfaces the object supports and returns to the invoking application pointers to those interfaces. In a preferred embodiment, the method IUnknown::QueryInterface is used tbr this purpose. Interfaces 703 through 706 are examples of typical interfaces that can be supported by an object. These imerfaces derive from the IUnknown interface. For example, the IDataObject interface 703 provides methods for storing data in and retrieving data from the object. The IOLEContainer interface 704 provides methods for listing the containee objects that are contained within the object. The IPersistStorage interface 705 provides methods for storing the object to and retrieving the object from persistent storage. The IOLEObject interface 706 provides methods through which a container application invokes the functionality of an object that corresponds to a user-selected action.
In addition to the API, the object linking and embedding facilities of the present invention provide information to container and server applications through a persistent global "registry." This registry is a database of information such as (1) for each type of object, the server application that implements the object type, (2) the actions (verbs) that each server application provides to container applications, (3) where the executable files for each server application are located, and (4) whether each server application has an associated object handler.
2. In-Place Interaction Overview
Once objects have been linked or embedded into a document, a user can select objects and request that certain actions be performed upon the selected objects. A user requests actions by first selecting the object and then selecting an action (e.g., a menu item) to be performed upon the object. The implementing server application is then invoked to perform the selected action. One skilled in the art will appreciate that there are many ways to display the choices of possible actions to a user and allow the user to select an action. In a preferred embodiment, the container application determines from the global registry what actions hre supported by the server application implementing the selected object and then displays the actions in a menu.
FIG. 8 is a sample user menu provided by a container application to display and select the actions available for an object. Menu item 803 is the entry for the object on the container application Edit menu 802. The entry varies based on the currently selected object. When no embedded or linked objects are selected, menu item 803 is not displayed. Submenu 804 displays the actions supported by an "Excel Worksheet Object." In this example, the supported actions are "Edit," "Open," and "Type." The first action (e.g., "Edit") on a submenu is the default action, which is performed when a user double-clicks with a mouse pointing device on the object, or enters functionally equivalent keys.
Once a user has selected a desired action (from the menu or by double-clicking on the object), the container application can then invoke the server application passing it an indication on the action to perform on behalf of the container application. The container application does this by obtaining the IOLEObject interface for the object and then invoking the object's DoVerb method passing it the selected action. (The DoVerb method performs the object-specific actions on the object.) The server application in turn determines whether the object can be activated in place within the window environment of the container application. If so, the server application and container application merge their menus into a composite menu bar, negotiate the placement of server application tool bars, palettes, formula bars, etc., and set up merged message handling. At this point, the server application is ready to receive user input.
Continuing the example of FIG. 4, FIG. 4 shows the user editing the spreadsheet object (the budgeting data 405) in place within the window environment of a word processing application. FIG. 9 is a diagram showing the composite menu bar resulting from the merger of the server application menus with the container application menus of the example shown in FIG. 4. The composite menu bar 901 comprises menus 902, 905 from the word processing application and menus 903, 904, 906 from the spreadsheet application. When the user selects a particular menu item from one of these menus, the container application through the merged message handler determines whether to dispatch the message to the word processing application or to the spreadsheet application.
In a preferred embodiment of the present invention, a composite menu bar is created based upon a set of predetermined conventions. Each application menu to be included in the composite menu bar is assigned to a menu group. The menus are then inserted into the composite menu bar according to the assigned menu group.
FIG. 10 is a diagram of the menu groups that compose a composite menu bar in a preferred embodiment of the present invention. The composite menu bar 1003 comprises menu groups 1001 from the container application and menu groups 1002 from the server application. The container application menu groups 1001 include the File group, the Container group, and the Window group. The server application menu groups 1002 include the Edit group, the Object group, and the Help group. In a preferred embodiment, the container and server application menus are interleaved in the final composite menu bar, according to the Microsoft application user interface style guidelines, which is specified in "The Windows Interface: An Application Design (Guide," Microsoft Corp., 1992, which is herein incorporated by reference. Specifically, in the composite menu bar 1003, the groups are arranged left to right in the following order: File, Edit, Container, Object, Window, and Help.
3. Window Support for In Place Interaction
In a preferred embodiment, the in-place interaction API is implemented using the capabilities of the underlying window system. The present invention is described assuming the underlying window system is similar to the Microsoft Windows 3.1 operating system ("Windows"), although one skilled in the art will appreciate that the present invention can be implemented in a different underlying window system. The Microsoft Windows 3.1 operating system is described in "Programmer's Reference, Volume 2: Functions," Microsoft Corp., 1992; "Programmer's Reference, Volume 3: Messages, Structures, and Macros," Microsoft Corp., 1992; and "Guide to Programming," Microsoft Corp., 1992, which are herein incorporated by reference.
In window environments, applications support a single document interface or a multiple document interface. A single document interface ("SDI") application interacts with one document (file) at a time. For example, a word processing application that supports SDI would display the file currently being edited in its primary window. A multiple document interface ("MDI") application interacts with multiple documents (files) by devoting at least one window to each document. For example, a word processing application that supports MDI might display each file currently being edited in a separate document window. The user selects the document window of the file the user wishes to edit either by clicking on the title bar of the desired document window or by selecting the window title from a list on the Window menu of the application.
FIG. 11 is a diagram showing the component windows of a typical Single Document Interface application. A typical SDI application provides a frame window 1101, and, depending upon the application, may additionally provide pane windows 1105 and 1106 and a parent window 1107 for an embedded object resides. In the case of an SDI application, the frame window 1101 is also the document window. Pane windows 1105, 1106 provide multiple views of a compound document. A parent window 1107 may be created by the container application to delineate the object when the object is first inserted into the compound document. In the example shown in FIG. 11, the embedded object is a spreadsheet object, which is displayed within an object window 1108, which is contained within the parent window 1107 of the container application. The object window 1108 is owned by the server application. The frame window 1101 contains a title bar 1102, a menu bar 1103, and a tool bar 1104. Typically, tool bars and other application-specific tools are attached to either the frame window or a pane window of a container application. They may also appear as floating palettes, which are windows that are independent of the windows shown in FIG. 11 and thus appear to "float" on top.
FIG. 12 is a diagram showing the component windows of a typical Multiple Document Interface application. A typical MDI application allows a user to edit multiple compound documents from within the same container application. In the example shown in FIG. 12, the user edits two separate compound documents in the two document windows 1205, 1206. Each document window can contain pane windows in a manner analogous to the SDI application. Document window 1205 contains two pane windows 1207, 1208. Also, the MDI application can provide a parent window 1209 for containing embedded objects in a manner analogous to the SDI application. FIG. 12 shows an embedded spreadsheet object presented within an object window 1210. As in the case of an SDI application, the application-specific tools may appear anywhere.
The windows managed by either an SDI or MDI application are created and maintained in a hierarchical fashion. FIG. 13 is a block diagram showing the typical window hierarchy of a container application when it is editing an embedded object in place. The window hierarchy comprises container application windows 1301 from the container application, and server application windows 1307 from the server application. The container application 1302 manages its frame window 1303, which contains a document window 1304, which may contain a pane window 1305, which may contain a parent window 1306. When an object is activated in place, the server application 1308 creates a root window 1309 for the embedded object and any child windows it requires. The object root window 1309 contains object child windows 1310, 1311, 1312.
Every application, when implemented as a separate process, contains an input queue for receiving events connected with the windows residing in the application's window hierarchy. The window hierarchy of FIG. 13 is supported by two different applications. Thus, there are separate input queues associated with the windows belonging to the container application and the windows belonging to the server application. Input queue 1313 is associated with the container application windows 1301. Input queue 13 14 is associated with the server application windows 1307. In order to receive user input, a window is displayed. When a user clicks with the mouse, or inputs keystrokes to one of these windows, the underlying window system puts an appropriate message on either the container input queue 1313 or the server application queue 1314.
4. In-Place Interaction API
The object linking and embedding API provides functions and defines interfaces through which the container and server applications communicate to support in-place interaction. The methods of these interfaces and the other API functions are invoked by application code in the usual course of processing user input. In an event-driven windowing system, an application invokes the appropriate method or function in response to receiving a message indicating that a user has selected a particular menu item or object.
FIG. 14 is a flow diagram showing message processing in an event-driven windowing operating system environment. Each window has its own message handler, which is registered with the underlying window system when the window is created. Several windows may share a single message handler. When messages are received on an application input queue (for example, the input queue of the container application 1313), the application filters, translates, or dispatches the message to the window system. The window system dispatcher in turn sends the message to the message handling function (the "message handler") that was previously registered for the particular window indicated in the message. Upon receipt of the message, the message handler processes the message. The processing may include using the object linking and embedding API. Steps 1401 and 1402 compose a message pump. In step 1401, the application waits for a message on its input queue. In step 1402, the application filters or translates the message, if appropriate, or dispatches the message to the window system dispatch function. Steps 1403 and 1404 are the steps in the window system dispatch function that dispatch the message to the appropriate window message handler. In step 1403, the window system dispatcher locates the message handler for the window that is indicated in the message. In step 1404, the window system dispatcher sends the message to the located message handler (e.g., by invoking the message handler).
Steps 1405 through 1412 compose a typical message handler for a window. A message handler is also referred to as a "window procedure." In a preferred embodiment, if an application does not provide a window procedure for a particular window, the underlying window system provides a default message handler called DefWindowProc. In steps 1405 through 1408, the application decodes the message to determine what type of event has occurred. Typically, for each type of event, the application invokes a different function, as shown in steps 1409 through 1412. These functions may in turn use the object linking and embedding API. For example, when a menu event is received, the application, in step 1411, invokes a function that processes menu events. If a contained object is selected before a menu event that can cause the object to be activated in place, then in step 1411 the application invokes the Process.sub.-- Object.sub.-- Activation function (shown as step 1413), which activates the selected containee object in place. As will be discussed further below, the Process.sub.-- Object.sub.-- Activation function uses the object linking and embedding API to activate a containee object in place.
The in-place interaction API defines the following interfaces: IOLEWindow, IOLEInPlaceUIWindow, IOLEInPlaceFrame, IOLEInPlaceParent, and IOLEInPlaceObject. The IOLEWindow interface provides a method for retrieving the window handle associated with one of the other interfaces. The IOLEInPlaceUIWindow interface provides methods through which a server application negotiates with a container application for placement of window tools. The IOLEInPlaceFrame interface provides methods through which a server application communicates with the frame window of a container application. The IOLEInPlaceParent interface provides methods through which a server application communicates with the parent window of a container application. The IOLEInPlaceObject interface provides methods through which a container application activates and deactivates a server application. FIG. 14B is a block diagram showing the public interfaces required to support in-place interaction. The container object 14B01 supports the IOLEUIWindow interface 14B02, the IOLEInPlaceParent interface 14B03, and the IOLEInPlaceFrame interface 14B04. The containee object 14B05 supports the IOLEInPlaceObject interface 14B06. Each of these interfaces is described below in detail.
4.1 IOLEWindow Interface
Table 2 lists the IOLEWindow interface. In object-oriented parlance, the IOLEWindow interface is the "base class" for the other in-place interaction interfaces. Thus, the other interfaces are derived from the IOLEWindow interface and inherit its public methods. In the IOLEWindow interface there is only one public method called GetWindow.
TABLE 2
______________________________________
interface IOLEWindow: public IUnknown {public:
virtual SCODE GetWindow (HWND FAR *phwnd) = 0;
______________________________________
4.1.1 IOLEWindow::GetWindow
The GetWindow method retrieves the window handle (unique window identifier) corresponding to the IOLEInPlaceUIWindow, IOLEInPlaceFrame, IOLEInPlaceParent, or IOLEInPlaceObject interface from which it was invoked. The retrieved window handle is typically used when invoking underlying window system functions.
4.2 IOLEInPlaceUIWindow Interface
Table 3 lists the IOLEInPlaceUIWindow interface. The IOLEInPlaceUIWindow interface methods are invoked by a server application to negotiate tool placement within the document and pane windows of a container application.
TABLE 3
______________________________________
interface IOLEInPlaceUIWindow: public IOLEWindow {public:
virtual SCODE GetBorder (RECT borderRect) = 0;
virtual SCODE QueryBorderSpace (RECT widthRect) = 0;
virtual SCODE SetBorderSpace (RECT widthRect) = 0;
______________________________________
4.2.1 IOLEInPlaceUIWindow::GetBorder
The GetBorder method retrieves the location where the server application is allowed to place its tools (which are implemented as child windows). This method returns a rectangle located inside the frame of either a document or pane window, depending upon whether the document or pane interface was invoked. Once the server application has retrieved this rectangle, it can determine the width of space it needs to place any tools and can then request this space using the QueryBorderSpace method. If the rectangle returned by the container application is rejected, the server application can choose not to continue with activation in place or can choose to not activate its tools.
4.2.2 IOLEInPlaceUIWindow::QueryBorderSpace
The QueryBorderSpace method retrieves the designated amount of space in a pane or document window where the server application can place its tools. The method takes one parameter, a rectangle of border space, within the rectangle retrieved from a previous call to GetBorder, that the server application needs for its tool placement. The method returns an indication as to whether the document or pane window is able to accommodate the request. If the request cannot be accommodated, the server application can invoke the method again with a different rectangle, can choose not to continue activation in place, or can choose to not activate its tools.
4.2.3 IOLEInPlaceUIWindow::SetBorderSpace
The SetBorderSpace method informs its associated container application that it is actually allocating the designated space in the pane or document window to place the server application's tools. This method is called after the space has been successfully requested from the pane or document window in a previous call to QueryBorderSpace. The server application is responsible for allocating the space it needs. The method takes one parameter, the rectangle of space the server application is allocating to its tool child window. The designated rectangle may be smaller than that successfully previously requested. The term "designated" refers to a passed in parameter and "specified" refers to the interface, class, window, or object to which a particular method belongs. The method moves or sizes, as necessary, any of the specified pane or document window user interface resources.
4.3 IOLEInPlaceFrame Interface
Table 4 lists the IOLEInPlaceFrame interface. The IOLEInPlaceFrame interface provides methods invoked by a server application to communicate with the frame window of its container application.
TABLE 4
______________________________________
interface IOLEInPlaceFrame: public
IOLEInPlaceUIWindow {public:
virtual SCODE SetMenu (HANDLE hSharedMenu,
HWND hwndObject) = 0;
virtual SCODE InsertMenus (HANDLE hmenu,
UINT FAR *lpiMenuCounts) = 0;
virtual SCODE RemoveMenus (HANDLE hmenu) = 0;
virtual SCODE SetStatusText (LPSTR lpszStatusText) = 0;
virtual SCODE EnableModeless (BOOL fEnable) = 0;
virtual SCODE TranslateAccelerator
(LPMSG lpmsg, WORD WID) = 0;
______________________________________
4.3.1 IOLEInPlaceFrame::SetMenu
The SetMenu method installs and removes the designated composite menu bar as the menu bar of the container application and installs a message handler for the composite menu bar. FIG. 15 is a flow diagram of an implementation of the IOLEInPlaceFrame::SetMenu method. This method uses different mechanisms to install the composite menu bar depending upon whether the container application is an MDI or SDI application. In step 1501, the method determines whether the designated composite menu bar is NULL and, if so, continues at step 1502, else continues at step 1503. In step 1502, the method invokes the helper function ObjectSetMenuDescriptor to remove the message handler for the composite menu bar, and returns. In step 1503, the method determines whether the container application is an SDI application, and if it is, continues at step 1504, else continues at step 1505. In step 1504, the method invokes the underlying window system function SetMenu to install the composite menu bar as the menu bar of the container application frame window, and then it continues at step 1507. In step 1505, the method sends a message to the frame window telling it to perform its MDI menu setup. In step 1506, the method invokes the underlying window system function DrawMenuBar to redraw the menu bar. In step 1507, the method invokes the helper function ObjectSetMenuDescriptor to install the message handler for the composite menu bar. In step 1508, the method performs any other processing that may be required at the time of changing its menu bar and then returns.
4.3.2 IOLEInPlaceFrame::InsertMenus
CODE TABLE 1
__________________________________________________________________________
VOID IOleInPlaceFrame::InsertMenus (hmenu, ContrCounts) {
1 if there are File Group menus present {
2 for each filegroupmenu {
3 hfilemenu = CreateMenu ( );
4 InsertMenu (hmenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vertline.M
F.sub.-- POPUP, hfilemenu);
5 ContrCounts[0] = ContrCounts[0] + 1;
6 for each filegroupmenu.sub.-- item {
7 InsertMenu (hfilemenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vert
line.MF.sub.-- STRING,
8 item.sub.-- id, "string to be displayed");
9 }
10 };
11
if there are Container Group menus present {
12 for each containergroupmenu {
13 hcontmenu = CreateMenu ( );
14 InsertMenu (hmenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vertline.M
F.sub.-- POPUP, hcontmenu);
15 ContrCounts[1] = ContrCounts[1] + 1;
16 for each contgroupmenu.sub.-- item {
17 InsertMenu (hcontmenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vert
line.MF.sub.-- STRING,
18 item.sub.-- id, "string to be displayed");
19 }
20 };
21
if there are Window Group menus present {
22 for each windowgroupmenu {
23 hwndmenu = CreateMenu ( );
24 InsertMenu (hmenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vertline.M
F.sub.-- POPUP, hwndmenu);
25 ContrCounts[2] = ContrCounts[2] + 1;
26 for each wndgroupmenu.sub.-- item {
27 InsertMenu (hwndmenu, MF.sub.-- APPEND, MF.sub.-- BYPOSITION.vertl
ine.MF.sub.-- STRING,
28 item.sub.-- id, "string to be displayed");
29 }
30 };
31
return( );
__________________________________________________________________________
The InsertMenus method inserts the menus of the container application into the composite menu bar being created by the server application. Code Table 1 shows pseudo-code for an implementation of the IOLEInPlaceFrame::InsertMenus method. The method takes two parameters: a composite menu bar and an array of menu counts. For each of the menu groups represented by the menus of the container application, there is a loop which inserts the menus for that group. In lines 1-10, if there are any File group menus, then the method inserts these menus in the composite menu bar, and increments the menu count array at the index corresponding to the File group. (For example, index=0 if the menu bar presented in the example of FIG. 4 is used.) In lines 11-20, if there are any Container group menus, the method inserts these menus into the composite menu bar and increments the menu count array at the index corresponding to the Container group. Finally, in lines 21-30, if there are any Window group menus to be added, the method inserts these menus into the composite menu bar and. then increments the menu count array at the index corresponding to the Window group. At the completion of this method, the value stored at each index in the menu count array indicates the number of menus that the container application inserted for that particular menu group. The method invokes standard functions from the underlying window system (CreateMenu and InsertMenu) to create the menus for the container application and to insert them in the composite menu bar.
4.3.3 IOLEInPlaceFrame::RemoveMenus
The RemoveMenus method allows the container application to remove its menus from the composite menu bar before the server application deallocates the composite menu bar. This method is invoked from the IOLEInPlaceObject::InPlaceDeactivate method. The RemoveMenus method takes one parameter: the handle of the composite menu bar where the container menus are stored. The composite menu bar is expected to be clear of all server menus before this method is invoked.
4.3.4 IOLEInPlaceFrame::SetStatusText
The SetStatusText method allows the server application to set the status window (if there is one) of the container application's frame window. Typically, the status window is located at the bottom of the frame window and contains status or hinting information corresponding to the current selection. The SetStatusText method is container application specific and will perform whatever operations the container application usually performs to set its status window. The method takes one parameter: the text string to insert in the status window.
4.3.5 IOLEInPlaceFrame::EnableModeless
The EnableModeless method enables or disables the currently displayed modeless dialog for the container application. A modeless dialog is an input window which is displayed until it is explicitly closed by the user. While this window is displayed, the user is able to interact with other windows. A modal dialog, on the other hand, is an input window which blocks out other window processing until the user enters acceptable input. This method is invoked by a server application when it wants to display a modal dialog, but and its associated container application is already displaying a modeless dialog.
FIG. 16 is a flow diagram of an implementation of the IOLEInPlaceFrame::EnableModeless method. This method hides the modeless dialog of the container application, and when called again restores the modeless dialogs. If the designated flag fEnable is true, then the hidden dialogs are displayed, otherwise any currently displayed modeless dialogs are hidden (removed from display, but in-memory data structures not deallocated). In step 1601, the method determines whether FEnable is true, and, if it is, continues at step 1602, else continues at step 1603. In step 1602, the method invokes an underlying window system function ShowWindow to restore the windows associated with the previously saved modeless dialogs, and then returns. In step 1603, the method saves the window handle of the next currently displayed modeless dialog. In step 1604, the method invokes an underlying window system function ShowWindow to hide the window associated with the modeless dialog. In step 1605, the function checks to see if there are any more modeless dialogs displayed, and, if there are, the function loops back to step 1603, otherwise the function returns.
4.3.6 IOLEInPlaceFrame::TranslateAccelerator
The TranslateAccelerator method allows a container application to process accelerator key combinations when a server application receives a keystroke it does not recognize. Accelerator key combinations are keyboard shortcuts for menu commands and are discussed further below. The TranslateAccelerator method is invoked indirectly by the function ObjectTranslateAccelerator which is called in the server application message pump. The container application should perform its normal accelerator processing and then return an indication of whether or not the accelerator was processed. This value is then passed on to the server application by the function ObjectTranslateAccelerator. Note that because the message has been transferred from the server application to the container application, the underlying window system may not have retained any additional key state or message information associated with the designated message.
4.4 IOLEInPlaceParent Interface
Table 5 lists the IOLEInPlaceParent interface. The IOLEInPlaceParent interface provides the methods invoked by the server application to communicate with the parent window. This window is also referred to as the in-place "container site" for the object.
TABLE 5
______________________________________
interface IOLEInPlaceParent:
public IOLEWindow {public:
virtual SCODE CanInPlaceActivate ( ) = 0;
virtual SCODE OnInPlaceActivate ( ) = 0;
virtual SCODE OnUIActivate ( ) = 0;
virtual SCODE OnUIDeactivate ( ) = 0;
virtual SCODE OnDeactivate ( ) = 0;
virtual SCODE ShadeBorder (LPRECT lprect,
DWORD grfState) = 0;
virtual SCODE GetWindowContext
(IOLEInPlaceFrame *pFrame, IOLEInPlaceUIWindow
*pDoc, IOLEInPlaceUIWindow *pPane, LPRECT
lprectChildPosition, HANDLE *hAccelTable) = 0;
______________________________________
4.4.1 IOLEInPlaceParent::CanInPlaceActivate
The CanInPlaceActivate method is used by the server application to determine whether the container application supports in-place interaction. This method gives the container application a chance to accept or refuse the activation in place of a selected containee object. The method returns an indication of whether the container application is allowing in-place interaction.
4.4.2 IOLEInPlaceParent::OnInPlaceActivate
The OnInPlaceActivate method is invoked by a server application to give its container application a chance to perform any necessary operations before the server application creates the new composite menu bar (at activation time). FIG. 17 is a flow diagram of an implementation of the IOLEInPlaceParent:: OnInPlaceActivate method. In this implementation, the only operation performed is setting a flag in step 1701 indicating that a containee object has been activated. This information is used later, whenever the specified object's parent container object is asked to activate or deactivate. This flag tells the parent container application whether it needs to activate or deactivate an object contained within it (a nested object), instead of activating or deactivating its own user interface.
4.4.3 IOLEInPlaceParent::OnUIActivate
The OnUIActivate method removes all of the container application menus and tools in preparation for activation of a containee object in place. FIG. 18 is a flow diagram of an implementation of the IOLEInPlaceParent::OnUIActivate method. The steps performed by the method depend on whether the container object is itself an object that has been activated in place. In step 1801, the method determines whether the container object has been activated in place. If it has not, the method continues at step 1802, else it continues at step 1803. In step 1802, because the container object is a top level container object (not activated in place), the method uses its normal procedure to remove the container application menus and any extraneous tools, and then returns. In step 1803, because the container object is also a containee object, the method retrieves the object's own IOLEInPlaceObject interface to access the methods that treat the container object as a containee object. In step 1804, the method invokes the activate method of the container object to deactivate itself. In step 1805, the method hides all of the container object's document and pane window level tools. In step 1806, the method invokes the shade border method of the parent container object to remove the in-place interaction user feedback from around the container object and returns. The container object's object window is actually deactivated at a later time (e.g., when the containee object deactivates).
4.4.4 IOLEInPlaceParent::OnUIDeactivate
The OnUIDeactivate method is invoked by a server application at the erid of deactivating its user interface resources to allow its parent container application to either activate its own user interface or invoke its parent container application to allow the parent container application to activate its user interface. FIG. 19 is a flow diagram of an implementation of the IOLEInPlaceParent::OnUIDeactivate method. This method provides two different behaviors depending upon whether the container object is itself a containee object or is a top level container object. In the former case, if this container is to become the new object activated in place, then its own user interface is activated, otherwise the container requests its parent container application to activate its user interface. In the latter case, the container application restores its user interface using normal procedures. In step 1901, the method clears the flag indicating that the container application has activated a .containee object. In step 1902, the method determines whether the specified container object is a containee object, and if it is not, continues at step 1903, else continues at step 1905. In step 1903, the method sets the container application menus and its title bar using normal procedures, and continues in step 1904 to set the input focus to the desired window, and returns. The input focus is set to a particular window when that window is to receive keyboard input. In step 1905, the method examines the flag ABOUT.sub.-- TO.sub.-- ACTIVATE to determine whether the container object is about to become the activated object, and if it is not, continues at step 1906, else continues at step 1907. (The ABOUT.sub.-- TO.sub.-- ACTIVATE flag is set when the container application is selected by the user, e.g., in the Process.sub.-- Mouse.sub.-- LButtonUp function discussed in detail below.) In step 1906, the method invokes the IOLEInPlaceParent::OnUIDeactivate method of the container object to activate the user interface of the container application of the parent container object, and returns. In step 1907, the method invokes function ActivateUI to activate the user interface of the container application, and returns.
4.4.5 IOLEInPlaceParent::OnDeactivate
The OnDeactivate method is invoked by the server application to give its associated container application a chance to free any resources or set flags associated with the activated containee object before the containee object is fully deactivated. The method is invoked from the OLEInPlaceObject::InPlaceDeactivate method of the containee object.
4.4.6 IOLEInPlaceParent::ShadeBorder
The ShadeBorder method draws or removes a hatched pattern border from around the selected, or about to be deselected, containee object. The hatched pattern border is used to give the user feedback that the containee object has been activated in place. This method can invoke the helper object linking and embedding API function ObjectShade to create the proper shading pattern. The method takes two parameters: a rectangle surrounding the object where the border should be placed and a set of flags. The set of flags indicates whether the border should be on (SHADEBORDER.sub.-- ON=1) or off and whether the border should be drawn in the same color as the text contained in the title bar of the active window (SHADEBORDER.sub.-- ACTIVE=1) or the same color as disabled text. The active window is the window that has input focus.
4.4.7 IOLEInPlaceParent::GetWindowContext
The GetWindowContext method returns the set of container application interfaces associated with a particular containee object. Specifically, it returns the following parameters:
pFrame, which is a pointer to an IOLEInPlaceFrame interface;
pDoc, which is a pointer to an IOLEInPlaceUIWindow interface;
pPane, which is a pointer to an IOLEInPlaceUIWindow interface;
lprectChildPosn, which is a pointer to the location where the associated IOLEInPlaceParent instance will display the object window of the object within the parent window; and
hAccelTable, which is a handle to the container application's accelerator table (described below).
These values are used by the server application to negotiate and handle activation and deactivation. This method creates and associates instances of these interfaces with the relevant frame, document, pane, and parent windows of the container application.
4.5 IOLEInPlaceObject Interface
Table 6 lists the IOLEInPlaceObject interface. The IOLEInPlaceObject interface methods are invoked by a container application to activate and deactivate a contained object. Some of these methods access contained objects in a nested fashion, through the containment hierarchy. Others access only the current active object, which is the containee object displaying the editing menus. An alternative implementation would split this interface into two others: one to access only the active object and another to access a containee object through the containment hierarchy.
TABLE 6
______________________________________
interface IOLEInPlaceObject: public IOLEWindow {public:
virtual SCODE InPlaceDeactivate ( ) = 0;
virtual SCODE InPlaceUIDeactivate ( ) = 0;
virtual SCODE TranslateAccelerator (LPMSG lpmsg) = 0;
virtual SCODE Activate (BOOL fActivate,
BOOL fDocActivate) = 0;
virtual SCODE ResizeBorder (RECT borderRect) = 0;
virtual SCODE EnableModeless (BOOL fEnable) = 0;
virtual SCODE SetVisRect (LPRECT lprect) = 0;
______________________________________
4.5.1 IOLEInPlaceObject::InPlaceDeactivate
The InPlaceDeactivate method is invoked by a container application to completely deactivate a containee object after an "undo" operation no longer needs to access the containee object and before the container application closes. This method performs the final deallocation of any resources associated with the activation of the containee object in place. FIG. 20 is a flow diagram of an implementation of the IOLEInPlaceObject:: InPlaceDeactivate method. The method first determines whether it has activated a (nested) object contained within it, and if it has, it invokes the nested object's InPlaceDeactivate method. Otherwise, the object deactivates itself. In step 2001, the method determines whether the specified object is also a container object and has activated a nested containee object. If it has, the method continues at step 2002, else it continues at step 2004. In step 2002, the method retrieves the IOLEInPlaceObject interface of the activated containee object (which the server application of the specified object has previously stored), and in step 2003 invokes IOLEInPlaceObject::InPlaceDeactivate method of the retrieved interface, and then returns. In step 2004, the method checks to see whether the specified object's user interface is still active, and if it is, continues at step 2005, else continues at step 2006. In step 2005, the method invokes the specified object's InPlaceUIDeactivate method to deactivate its own user interface, and then continues at step 2006. In step 2006, the method invokes a server application function Remove.sub.-- Menus to remove the server application menus from the composite menu bar. In step 2007, the method invokes the IOLEInPlaceFrame::RemoveMenus method of the specified object's container object to allow the parent container application to remove its menus from the composite menu bar. In step 2008, the method invokes the object linking and embedding API function ObjectDestroySharedMenu to deallocate the structure for the composite menu bar. The ObjectDestroySharedMenu function is window system specific and invokes whatever underlying window system functions are necessary to deallocate structures associated with a composite menu bar. In step 2009, the method invokes the underlying window system function DestroyMenu to deallocate the composite menu bar structure and to deallocate the window associated with the specified object. Finally, in step 2010, the method invokes the IOLEInPlaceParent:: OnDeactivate method of the specified object's container object, and returns.
4.5.2 IOLEInPlaceObject::InPlaceUIDeactivate
The InPlaceUIDeactivate method hides all of the user interface elements associated with the specified object that has been activated in place. This method is invoked either by the container application when it processes the user selection of a different object or area within the compound document, or from the specified object's InPlaceDeactivate function if the specified object's user interface has not yet been deactivated (See FIG. 20). FIG. 21 is a flow diagram of an implementation of the IOLEInPlaceObject::InPlaceUIDeactivate method. This method first determines whether the specified object is a container object and has activated a nested object, and if so invokes the nested object's InPlaceUIDeactivate function. Otherwise, the method hides its own user interface and informs its container application that it has deactivated its user interface. In step 2101, the method determines whether the flag indicating that a nested containee object has been activated in place is true, and if so, continues at step 2102, else continues at step 2104. In step 2102, the method retrieves the IOLEInPlaceObj ect interface for the activated nested containee object, and in step 2103 invokes the nested containee object's InPlaceDeactivate method, and returns. In step 2104, the method clears the flag ABOUT.sub.-- TO.sub.-- ACTIVATE to indicate that the user has selected a different object. In step 2105, the method invokes the specified object's Activate method sending it a parameter of false to request the method to deactivate. This method removes all of the specified object's user interface elements that were associated with the parent container application frame window. In step 2106, the method invokes the object linking and embedding API function SetActiveObjectHwnd to remove the specified object's IOLEInPlaceObject interface from its association with the parent container application document window. This means that if the container application is an MDI application, and if the user later selects this document window, the specified object will no longer be reactivated in place. In step 2107, the method uses an underlying window system function to hide any user interface elements belonging to the server application that were associated with the parent container application's pane or document window. In step 2108, the method invokes the IOLEInPlaceParent:: ShadeBorder method of the specified object to remove the hatched border pattern feedback from around the deactivating object. In step 2109, the method invokes an underlying window system function to hide the window associated with the specified object. Finally, in step 2110, the method invokes the IOLEInPlaceParent::OnUIDeactivate method to allow the container application to install its own user interface, and returns.
4.5.3 IOLEInPlaceObject::TranslateAccelerator
The TranslateAccelerator method allows a server application to process accelerator key combinations before the container application has a chance to process them. Accelerator key combinations are keyboard shortcuts for menu commands and are discussed further below. In a preferred embodiment of the present invention, the object activated in place, by convention, processes accelerator key combinations first. The Translate Accelerator method is invoked by the container application in its message pump (see Code Table 9). The only operation required to be performed by this method is to invoke the underlying window system function TranslateAccelerator with the specified server application accelerator table. Such invocation is not necessary if the containee object is implemented by a separate executable process, because the separate process receives these key combinations in its own message pump and the container application never receives them. In that case, the TranslateAccelerator method will do nothing.
4.5.4 IOLEInPlaceObject::Activate
The Activate method activates or deactivates the user interface elements installed in the frame window of the parent container application depending upon whether the designated flag fActive is true. or false. If called when an MDI document window is activated or deactivated, this method installs or removes the composite menu bar associated with the object activated in place and puts a hatched border pattern around the specified object if it is being activated. If called when the top level frame window is activated or deactivated, this method places a hatched border pattern around the specified object if it is being activated, otherwise removes it. In this case there is no need to activate or deactivate other user interface elements. FIG. 22 is a flow diagram of an implementation of the IOLEInPlaceObject::Activate method. In step 2201, the method determines whether it has been called as a result of activating or deactivating the top level frame window or an MDI (child) document window. If called as a result of activating or deactivating an MDI document window, the method continues at step 2202, else continues at step 2210. In step 2202, the method determines whether the specified object is to be activated, and if it is not, continues at step 2203, else it continues at step 2206. In step 2203, the method invokes the IOLEInPlaceFrame::SetMenu method of the parent container object to remove the composite menu bar associated with activation of the specified object in place. In step 2204, the method hides any user interface elements installed in the parent container application frame window. In step 2205, the method invokes the IOLEInPlaceParent::ShadeBorder method of the parent container object to remove the hatched border pattern from around the specified object, and returns. In step 2206, the method invokes the IOLEInPlaceFrame::SetMenu method of the parent container object to install the composite menu bar as the menu bar of the associated frame window. In step 2207, the method sets the title bar of the frame window of the container application to indicate that the container application has activated the specified object. In step 2208, the method invokes an underlying window system function to display any frame level user interface elements. In step 2209, the method invokes the IOLEInPlaceParent::ShadeBorder method of the parent container object to draw a hatched border pattern around the specified object, indicating that it has been activated in place, and returns. In step 2210, the method determines whether the specified object is to be activated, and if it is, continues at step 2209, else it continues at step 2211. in step 2211, the method removes the hatched border pattern from around the specified object, and returns.
4.5.5 IOLEInPlaceObject::ResizeBorder
The ResizeBorder method is called by the container application to request the server application to resize the user interface tools the server application has placed within the pane or document windows of its parent container application. In response to invocation of this method, the server application should begin another tool placement negotiation loop with the container application using the QueryBorderSpace and SetBorderSpace methods of the interface instance associated with the pane or document window.
4.5.6 IOLEInPlaceObject::EnableModeless
The EnableModeless method enables or disables the currently displayed modeless dialog for the server application. Typically, this method is implemented in a manner analogous to the IOLEInPlaceFrame::EnableModeless method, which is discussed above with reference to FIG. 16.
4.5.7 IOLEInPlaceObject::SetVisRect
The SetVisRect method is called by the innermost level container object to communicate the amount of the object actually visible. The visible (clipping) rectangle of the object may have changed, for example, due to border negotiation, scrolling, or sizing. The designated rectangle is the clipping rectangle and it is the server application's responsibility to resize the containee object window to the correct (clipped) visible size.
4.6 Other Server Application Functions
In a preferred embodiment, a server application provides the following set of functions: ActivateUI, CreateNewMenu, CreateObjectToolbars, and RemoveMenus. These functions are shared by multiple server application interfaces including IOLEInPlaceObject and IOLEObject.
4.6.1 ActivateUI
SCODE ActivateUl (IOLEInPlaceUIWindow *pDoc, IOLEInPlaceObject pObject)
The ActivateUI function is a function implemented by a server application to control activation of the designated containee object's user interface resources. This high level function activates the frame, document, and pane level user interface elements, draws the hatched border pattern around the object, and displays the composite menu bar. FIG. 23 is a flow diagram of an implementation of the ActivateUI function. The function takes two parameters: a pointer to a document interface and a pointer to a containee object. In step 2301, the function gets the window handles for the designated document window and the designated containee object. In step 2302, the function invokes the object linking and embedding API function SetActiveObjectHwnd to set the designated document window's currently active object to a pointer to the interface of the containee object. This enables a container application implemented as an MDI application to activate the proper containee object when one of its document windows is selected by the user. In step 2303, the function invokes IOLEInPlaceObject::Activate method to activate the designated object. In step 2304, the function invokes the underlying window system function ShowWindow to display any user interface elements associated with the container application pane or document windows. In step 2305, the function determines the dimensions of a border or rectangle to surround the designated containee object, and, in step 2306, the function invokes the IOLEInPlaceObject::ShadeBorder method of the designated containee object to draw a hatched border pattern around the designated containee object using this rectangle. In step 2307, the function sets the input focus to the object window of the designated containee object. Finally, in step 2308, the function invokes the underlying window system function DrawMenuBar to redisplay the composite menu bar, and returns.
4.6.2 CreateNewMenu
HANDLE CreateNewMenu (IOLEInPlaceFrame *pFrame)
CODE TABLE 2
__________________________________________________________________________
HANDLE CreateNewMenu (IOLEInPlaceFrame *pFrame) {
1 hmenu = CreateMenu ( );
2 pframe -> InsertMenus (hmenu, ContrCounts);
3 lpiMenuCount[0] = ContrCount[0];
4 lpiMenuCount[2] = ContrCount[1];
5 lpiMenuCount[4] = ContrCount[2];
6 if there are Edit group menus present {
7 for each editgroupmenu {
8 heditmenu = CreateMenu ( );
9 insertion.sub.-- point = lpiMenuCount[0] + lpiMenuCount[1] + 1;
10 InsertMenu (hmenu, insertion.sub.-- point, MF.sub.-- BYPOSITION.vert
line.MF.sub.-- POPUP,
11 heditmenu, NULL);
12 lpiMenuCount[1] = lpiMenuCount[1] + 1;
13 for each editgroupmenu.sub.-- item {
14 InsertMenu (heditmenu, -1, MF.sub.-- BYPOSITION.vertline.MF.sub.--
STRING, item.sub.-- id,
15 "string to be displayed");
16 }
17 };
18
if there are Object group menus present {
19 for each objectgroupmenu {
20 hobjmenu = CreateMenu ( );
21 insertion.sub.-- point = lpiMenuCount[0]+ lpiMenuCount[1] +
lpiMenuCount[2]
22 lpiMenuCount[3] + 1;
23 InsertMenu (hmenu, insertion.sub.-- point, MF.sub.-- BYPOSITION.vert
line.MF.sub.-- POPUP,
24 hobjmenu, NULL);
25 lpiMenuCount[3] = lpiMenuCount[3] + 1;
26 for each objectgroupmenu.sub.-- item {
27 InsertMenu (hobjmenu, -1, MF.sub.-- BYPOSITION.vertline.MF.sub.--
STRING, item.sub.-- id,
28 "string to be displayed");
29 }
30 };
31
if there are Help group menus present {
32 for each helpgroupmenu {
33 hhelpmenu = CreateMenu ( );
34 InsertMenu (hmenu, -1, MF.sub.-- BYPOSITION .vertline.MF.sub.--
POPUP, hhelpmenu,
35 NULL);
36 lpiMenuCount[5] = lpiMenuCount[5] + 1;
37 for each objectgroupmenu.sub.-- item {
38 InsertMenu (hhelpmenu, -1, MF.sub.-- BYPOSITION.vertline.MF.sub.--
STRING,
item.sub.-- id,
39 "string to be displayed");
40 }
41 };
42
hSharedMenu = ObjectCreateSharedMenu (hmenu, lpiMenuCount);
43
return (hSharedMenu);
}
__________________________________________________________________________
The CreateNewMenu function is a function implemented by a server application to manage the creation of a composite menu bar. This function allocates the structures associated with the composite menu bar, requests the container application to insert its menus, and inserts the server application menus. Code Table 2 represents an implementation of the CreateNewMenu function. In line 1, the function invokes an underlying window system function to create the data structure for the composite menu bar. In line 2, the function invokes the IOLEInPlaceFrame::InsertMenus method of the container application frame window to insert the container application menus into the composite menu bar. In lines 3-5, the function tracks the number of menus the container application inserted for each menu group. In lines 6-17, assuming the server application has Edit group menus, the function creates each Edit group menu and inserts it into the correct spot in the composite menu bar, keeping track of how many menus it inserted. The correct spot is calculated in line 9 by determining how many menus have already been inserted to the left. For the Edit group, this will be the number of menus the container application inserted as part of the Container Group plus the number of Edit group menus already inserted, plus one for the current insertion. In lines 18-30, 31-41, the function performs analogous steps for any menus belonging to the Object group and Help group respectively. In line 42, the function invokes the object linking and embe |