1
METHOD AND APPARATUS FOR
AUTOMATIC UNDO SUPPORT
FIELD OF THE INVENTION
This invention generally relates to the field of application program development, and more particularly to providing automatic support for undo, redo and abort transactions in a programming environment.
BACKGROUND
Providing support for undo, redo and abort transactions in an application program is traditionally a complex and errorprone task. For highly complex application programs, such as Computer Aided Design (CAD) projects, the task is particularly difficult. One reason for this difficulty is that CAD designs are frequently revised before a design is deemed completed. For example, designs frequently evolve and change according to revised design goals or when certain features do not yield desired results. Thus, in any particular design session, a designer may make many substantial changes to a design, where each change may then require changes to other components of the design. Consequently, implementation of a robust undo, redo or abort system becomes correspondingly complex. (For brevity, the term "undo", unless indicated otherwise by wording or context, refers to undo, redo, and abort operations performed by an application program. The term "reversion" will be used to refer to program code implementing such undo, redo, and abort support.)
Part of the reason for the difficulty in providing undo support in a solid modeling system is that there are no inverse operations for most Boolean operations applied to objects within a model. Hence, one must capture the details of what has changed at a very low level, e.g., at the data structure level. In addition, many user operations are often ill formed, causing the operation to fail after partial calculation of the user request, and leaving the model in an unstable state that requires correction.
Historically, there have been several methods of incorporating undo support within the source code of an application program. The simplest (and most limiting) has been to save to permanent storage a check-point version of a design in progress. This saved copy can be re-loaded if the design goes awry. There are significant problems with this approach, however. First, restorations are limited to the design as saved. Second, designs can be extremely complex, and significant resources (e.g., processor, memory, storage, etc.) and time can be required to save and re-load designs; this limits the frequency of such backups.
An improved method has been to utilize an object-based history mechanism. That is, design environments typically break a drawing into multiple objects, frequently arranged as a graph. Drawing objects can be made responsible for saving current state information before effecting a change to its state. The saved state information can be used to revert an object to a previous state. However, this approach also suffers several significant shortcomings. One shortcoming is that every object must properly handle reversions (e.g., have appropriate program code to perform an undo). Similar to a chain being only as strong as the weakest link, an entire undo mechanism can be compromised by one object's failure to properly restore its state. Another is that every object must consume Central Processing Unit (CPU) resources to effect the state saving, and may seriously degrade program performance.
2
Another method has been to maintain a list of inverse operations. If a user rotates an object by ninety degrees, an inverse operation is recorded to undo the rotation. But, this method has shortcomings. One is that performing an inverse
5 operation is generally at least as resource consuming as the original calculation to get to the current state. Another, more problematic shortcoming, is that some operations have no inverse. For example, application of a lossy filter discards original data that cannot be recovered.
1° Yet another method has been to maintain a history of design actions, where a reversion is effected by re-computing the entire design up to some previous state. This solution is similar to applying inverse operations, and overcomes the problem with lossy operations. However,
15 operations relying on real-time, transient, or random data still cannot be reversed. And, since a design may have a very large number of operations to recreate, this solution can also be extremely slow and resource intensive.
But, each of the above methods places a burden on an
20 application program designer (e.g., the CAD/CAM developer) to design and implement a complex reversion feature. Due to such complexity, a significant portion of application program design time can be expended in order to properly implement it and allow its use throughout the
25 application program. Also, there is no guarantee that it will be implemented correctly. And, since such a feature is integral to an application program, it is unlikely that resulting program code will be easily portable to a different
^ application program.
SUMMARY
A programming environment can be modified to provide automatic support for reverting program memory states.
35 Such memory reversions are used to provide automatic support for undo, redo, and abort operations for application programs written with the programming environment. Memory allocation code (e.g., functions, procedures, etc.) can be modified to mark allocated memory as protected, and
40 assign an exception handler to such memory. For example, a Microsoft Win32 exception filter can be associated with a memory region. (An exception filter decides, based on the exception details, whether the exception represents an attempt to modify memory which we have protected (as
45 opposed to any other memory, or other kind of exception).) An attempt to access the memory causes an exception to be generated; in the Win32 context, a memory management heap id made responsible for tracking whether accesses generate violations. This exception is caught (e.g., Win32
50 Structured Exception Handling), providing opportunity for the memory to be preserved before it is modified, and program execution continued. Previous program states can be retrieved by restoring such stored memory states.
55 BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is presented by way of example, and not by limitation, in the figures of the accompanying drawings. Like references within the specification correspond to similar drawing elements. 60 FIG. 1 illustrates portions of a generalized CAD environment.
FIG. 2 shows an event line representing a sequence of operations during execution of an application program. 65 FIG. 3 shows a transaction timeline.
FIG. 4 is a flowchart for one method of implementing reversions in an API.
3
FIG. 5 is a high-level program-operation flowchart illustrating how FIG. 4 operations are called during normal program execution.
FIG. 6 is a flow chart for integrating an application written with the API with program memory not allocated with the 5 API.
FIG. 7 is an exemplary operating environment for an application program written with the API.
DETAILED DESCRIPTION 10
Instead of requiring an application developer to worry about providing undo support, such support can be made automatic through incorporating functions provided by an Application Programming Interface (API), a programming language, or other programming environment. One particu- 15 lar implementation is to incorporate such support into memory management support for such environments. For example, in a modified API written for C++, the new and delete operators can be overloaded to provide this support. However, to implement this API, it is important to under- 20 stand generally how a program operates. In general, a program's execution can be viewed from one of two perspectives. A first "traditional" approach is to watch the actions taken by the program. As discussed in the background, various methods can be applied to reverse the 25 effects of the program's taking some action. A second, and better approach, is to track changes made to program memory (e.g., RAM or other permanent storage) which is storing the program's current state as the program operates. It is generally understood that program execution is data 30 driven. As a program runs, user operations cause changes to program data which effect program output (e.g., display) and stored program state data. If changes to display state and stored program state are tracked as they occur, then a particular user operation can be undone by restoring 35 memory storage to its pre-action state. As discussed below, this approach overcomes several prior-art limitations.
Unfortunately, it is not feasible to track every change made to every data bit of memory. Therefore, available memory can be allocated into memory blocks of redeter- 40 mined size (e.g., a standard system block size). During execution of the user operation, any modified memory blocks are saved for later restoration. For clarity, it is assumed that block saves are performed between known program operation states, e.g., checking for changes only at 45 the end of a transaction. For example, a current memory state can be recorded at the start of a user operation, such as changes to a design. At completion of the operation, the memory state of the blocks is compared to the saved state, allowing identification of changes made by the operation. 50
Exemplary Application Program
To give context for the API, it is assumed herein that a program developer is preparing a CAD application program with the API. A CAD program, being a highly complex and 55 resource intensive application, illustrates the flexibility of the claimed memory-based approach to reversion tracking. The term "reversion" is intended to include operation of the invention as incorporated into an API or other development environment. The terms "undo", "redo" and "abort" refer to 60 operations performed by the CAD program written with the API. Undo means to take a CAD design to a previous state. Redo means to undo an undo operation, e.g., to restore program operation to a later program state. Abort, similar to undo, means to stop a program operation and restore pro- 65 gram operation to a known previous state, and to forget the changes made during the stopped program operation
4
CAD program execution generally goes through three stages. During the first stage, a user/operator provides program selections, such as clicking on a button or performing a menu-selection, and the program proves feedback such as highlighting a selected button or object. During a second stage, the application program executes a user request that inspects or modifies program data. And, during the third state, the application program updates or displays user interface information in response to the user request, and performs any side effects related to the user request. The term "transaction" is used to refer one or more user-initiated actions ("identified transactions") and program responses thereto ("unidentified transactions").
A transaction is roughly a group of actions which are effectively inseparable, such that they are all either done or all not done. Generally, identified transactions are operations where a user has directed that some change be made to a CAD model. Unidentified transactions are behind the scenes or automatic actions. For example, there are events related to a mouse, such as move, button click, or drag events, that generate events, but are not recognized by the user as a transaction per se. (An event is essentially a notification to a program that some action has occurred.) Unidentified transactions can also include changes to how the model is viewed, but which do not actually change the model itself, as well as program responses to user actions, which include displaying the outcome of an operation by modifying a graphics scene to show a different view, dynamically rotating the model, highlighting selected objects, etc.
FIG. 1 illustrates portions of a generalized CAD environment. Shown are the CAD application program 30 itself, which contains program modules (written using the API supporting reversion) for performing undo 32, redo 34, and abort 36 operations in accordance with the teachings of the invention. The undo, redo, and abort operations each rely on memory management modules 38 described below. The CAD application program 30 is of a type supporting solid modeling of designs, such as the Mechanical Desktop® Release 3 program by Autodesk Inc. of San Rafael, Calif. Program 30 utilizes several Directed Acyclic Graph (DAG) data structures to track design data and design intent. These structures will be briefly discussed to provide a foundation for terminology used throughout this description. These DAGs are presented purely for exemplary purposes—other data structures, such as non-directional graphs, trees, etc., can also be used. And, although discussed separately, it is understood that these DAGs may be combined or arranged differently to achieve equivalent results. For example, BREP and graphics data for a part can be derived from the part's design capture recipe (which contains different types of nodes for parts, assemblies, and drawings).
A first DAG 40 roughly tracks an entire assembly. It is assumed that leaf-nodes of the graph contain individual parts of the assembly, where each part contains graphics primitives, such as the triangles and lines representing information that is presented to a user. This DAG is optimized for reading for rendering and selection. Different Levels of Detail for parts can be stored for a part, as well as data to allow portions of a scene to be spatially sorted to facilitate selection and culling.
A second DAG 42 tracks a solid model boundary representation (BREP) for a part (an integrated collection of objects). This DAG represents the boundary topology and shape of the part. Instead of defining a part as a collection of edges or points, a BREP defines a part with respect to one or more shells. A simple part with no cavities in it will have a single exterior shell. Each shell has one or more faces.
|
