Electrical computers and digital processing systems: interprogra – High level application control
Reexamination Certificate
2000-09-19
2004-06-29
Lao, Sue (Department: 2126)
Electrical computers and digital processing systems: interprogra
High level application control
Reexamination Certificate
active
06757905
ABSTRACT:
BACKGROUND
1. Field of Invention
This invention relates to the field of application development, and more particularly, to methods and systems that manage the behavior of multiple commands to provide synchronous operation of associated commands.
2. Background of Invention
A typical software application provides a user with a variety of operations that can be executed on the various types of data employed by the application. Each transforms one or more data objects in one or more contexts. A context is a mechanism for representing data to the user. Contexts include documents, windows, text entry fields, dialog boxes, pictures, and the like.
In an application based on an object oriented architecture, each user-level operation may be represented by any number of underlying command objects, each of which manages a specific function on a specific target data object(s) in a specific context. After a command object is executed on a given context, it is typically maintained until a new command object is created in order to execute another user action. Where an action affects more than one context, it is preferable that the command objects operating on the individual data objects be performed synchronously, thereby preserving to the user the appearance in the user interface of a single action.
One example of synchronous commands is the use of drag and drop actions in a graphical user interface, typically under the control of a mouse-type input device. To the user, the drag and drop action moves a piece of data from a source location, or context, to a target context. However, to the application, the locations themselves are contexts, and the drag and drop operation is typically represented by two command objects, one which operates on the source context to update it and remove a data object therefrom, and one that operates on the target context to update it with the dragged data object. To maintain the appearance of a single drag and drop action, these individual command objects must operate in synchrony on their respective contexts. Each context is independently updated, but to the user the appearance is of a unified action.
In most applications, it is desirable to provide a mechanism by which the user can perform an action, and undo that action if the result is dissatisfactory, or redo the action. Typically, the undo or redo actions are implemented as separate methods of a single command object that performs the action. In these instances, undoing and redoing the action is relatively straight forward and is provided in most conventional applications. Because there is only a single context as the target of the undo/redo, most such actions do not require synchronized commands, since the same target context is updated by each action.
However, where the original action affects two or more contexts, then an undo or redo of that action must restore the state of the both contexts. Because of the separate contexts, there needs to be a separate command object operating on each. Accordingly, because the user should perceive the undo or redo as a single action, the underlying command objects that execute the undo or redo must operate synchronously on their respective contexts. For example, in a word processor, a drag and drop operation of text data from one window to another results in two command objects, one to delete the text from the source window, and one to place the text in the target window. To undo the drag and drop action, the two command objects created to perform the drag and drop must execute their undo methods in synchrony.
One existing solution to synchronizing command objects in separate contexts is to identify a lowest common parent context that hierarchically contains the separate contexts. Typically between the parent context and the separate contexts there will be a number of intermediate contexts, each of which may have its own undoable command object. These undoable command objects are deleted, and an undoable command object is then posted in the parent context, allowing the operations in the separate contexts to be undone. The deletion of the command objects in the intermediate contexts is undesirable because these command objects are unrelated to the command objects in the separate contexts. Thus, the user loses the ability to undo these commands objects as an side effect of attempting to undo the command objects in the lower level separate contexts.
Accordingly, it is desirable to provide a method for synchronizing command objects that allows for unified execution and undoing of the commands on independent contexts.
SUMMARY OF THE INVENTION
The present invention overcomes the limitations of prior systems by linking individual command objects, each of which is responsible for its own methods for executing on data objects in the context it is associated with, and then synchronizing the execution and deletion of the linked command objects. When a synchronous user action is initiated, a command object is created in the context where the action originated, i.e., the source context, and a command object is created in the context where the action is targeted, i.e., the target context. The individual command objects are linked, so that one command object can be accessed and invoked in one context, when the other command object is invoked in an active context. This allows for synchronization of the execution of the command objects, so that both command objects are either done or undone at the same time. In this manner, the user will perceive the action as unified, even though it affects data objects in two contexts. The user can thus cause the do and undo method of one command object to be invoked, and the corresponding do or undo method of a linked command object will also be invoked.
In order to ensure that a command object can be undone only when another command object linked thereto is capable of being undone, the present invention provides for synchronizing the deletion of linked command objects. The command object may be deleted because it failed to execute properly, or because it was not undoable. When a command object is deleted, it is destroyed and can no longer be executed,.either to do or undo its affects on its data objects. Accordingly, when a command object is processed for execution, its delete state is determined and compared with the delete state of its linked command object. If these are different, it means that one command object has been deleted, and the other has not. Accordingly, the command object that has not been deleted is deleted. In this manner both of the command objects are either doable or undoable together, and if one has been deleted, and thus is undoable, the other is brought into synchrony. This way, the user is presented with a consistent ability to either undo or not undo both command objects to produce consistent results in the source and target contexts.
REFERENCES:
patent: 5263167 (1993-11-01), Conner, Jr. et al.
patent: 5307451 (1994-04-01), Clark
patent: 5416900 (1995-05-01), Blanchard et al.
patent: 5455599 (1995-10-01), Cabral et al.
patent: 5459832 (1995-10-01), Wolf et al.
patent: 5481710 (1996-01-01), Keane et al.
patent: 5519862 (1996-05-01), Schaeffer et al.
patent: 5522029 (1996-05-01), Hatfield
patent: 5530859 (1996-06-01), Tobias, II et al.
patent: 5530864 (1996-06-01), Matheny et al.
patent: 5560012 (1996-09-01), Ryu et al.
patent: 5566294 (1996-10-01), Kojima et al.
patent: 5604853 (1997-02-01), Nagashima
patent: 5659747 (1997-08-01), Nakajima
patent: 6167455 (2000-12-01), Friedman et al.
Berlage, T., and Genau A., “From Undo to Multi-User Applications,” Human Computer Interaction, Proceedings—Vienna Conference, VCHCI '93, Sep. 20-22, 1993.
Macgragor, M.D., “Developing MacApp Applications,” Journal of Object-Oriented Programming, vol. 4, No. 8, pp. 14-22, Jan. 1992.
Meyer, B., “Orject-Oriented Design: Case Studies,” Object-Oriented Software Construction, Prentice Hall International (UK) Ltd., Chapter 12, pp. 281-290, 1988.
Piersol, K., “Building and Opendoc Part Handler,” MacTech Magazine, Sep. 1994, [retrieved on
Becker Thomas W.
Friedman Gregory S.
Apple Computer Inc.
Fenwick & West LLP
Lao Sue
LandOfFree
Method and system for synchronous operation of linked... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for synchronous operation of linked..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for synchronous operation of linked... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3303524