UNDO and Redo in NX Open

This page combines the two dedicated NX Open Programmer's Guide pages on session state recovery: UNDO (Undo Marks) and NX Open and redo.

UNDO Marks

The UNDO methods provide a very easy and powerful way to ensure that the NX session and parts are returned to a valid state. Conceptually, using them is simple:

1. The programmer first creates an UNDO Mark. This saves the current state of NX.
2. If the program executes without error, the programmer calls the method to delete the undo mark (unless the UNDO Mark is visible and being provided to let the user UNDO the operations of the custom application).
3. If the program encounters an error and needs to recover, the programmer can return the NX state to that defined by the UNDO Mark.

Visible vs. Invisible UNDO Marks

The choice of visible or invisible UNDO mark depends on whether the programmer wants the user to be able to Undo the operations of an NXOpen program or not. Irrespective of visibility, the program should always return to the Undo mark and delete the mark for any block of code that is modifying (creating/deleting/editing) the NX session or part data. This includes helper-objects like builders.

• Do not overuse UNDO Marks — it takes time and space to save NX states. Only define UNDO Marks for significant or critical blocks of operations. The number of active UNDO marks in NX is limited to 200. Once that limit is reached, older marks are reused.
• Making an UNDO Mark Visible exposes it to the user in the UNDO menu list. Do not expose UNDO Marks to the user that are only used for internal error recovery.
• Visible UNDO Marks should only be used if you want the user to be able to undo the changes made by the custom application after the application has completed its function and returned control to NX.
• Take care to maintain a one-to-one mapping of UNDO Mark creation and either deletion or returning to the UNDO Mark.
• There are special cases where an UNDO mark may become invalid (e.g. if session state changes underneath it in ways that make replay impossible).

Code Examples

NXOpen C++:

// Create UNDO Mark
NXOpen::Session::UndoMarkId myMark;
myMark = theSession->SetUndoMark(NXOpen::Session::MarkVisibilityInvisible, "markName");
try
{
    // Success: Remove the UNDO Mark (because it is invisible)
    theSession->DeleteUndoMark(myMark, "markName");
}
catch (NXOpen::NXException &exceptionObject)
{
    // Error Reporting and Recovery
    try
    {
        // Return NX to valid state and remove the UNDO Mark
        theSession->UndoToMark(myMark, "markName");
    }
    catch(...)
    {
        // UNDO Failed: let user know that the part may be in an invalid state
    }
    theSession->DeleteUndoMark(myMark, "markName");
}

Legacy UF (C API):

UF_UNDO_mark_id_t myMark;
UF_UNDO_set_mark(UF_UNDO_invisible, myMarkName, myMark);
status = ........
if ( status != 0 )
{
    /* UNDO to the mark */
    status = ...
    theSession.undoToMark( myMark );
}
catch
{
   // UNDO failed, report to user
}
// UNDO successful, delete the undo mark
theSession.deleteUndoMark( myMark, markName );

NX Open for Python:

# Create UNDO Mark
markName = "My Undo Mark"
myMark = theSession.SetUndoMark(
    NXOpen.Session.MarkVisibility.Invisible, markName)
try:
    ...........
    # Success: Remove the UNDO Mark (because it is invisible)
    theSession.DeleteUndoMark(myMark, markName)
except NXOpen.NXException as exceptionObject:
    # Error Reporting and Recovery
    try:
        # Return NX to valid state and remove the UNDO Mark
        theSession.UndoToMark(myMark)
    except Exception as ex:
        # UNDO Failed: let user know that the
        # part may be in an invalid state
        # Replace pass with error recovery code
        pass
    theSession.DeleteUndoMark(myMark, markName)

(NX Open for .NET and Java follow the identical theSession.SetUndoMark / DeleteUndoMark / UndoToMark shape, adapted to each language's exception-handling syntax.)

Core Session methods used

• Session.SetUndoMark(MarkVisibility, markName) → returns an UndoMarkId
• Session.DeleteUndoMark(mark, markName)
• Session.UndoToMark(mark, markName)
• Session.MarkVisibility.Invisible / (implied) .Visible

NX Open and Redo

Redo in NX is implemented by recording function calls executed to perform an operation, then replaying those functions after an undo to redo the same operation.

Key facts:

• Only NX Open functions are recorded. UF calls are not recorded, because they cannot be redone properly.
• Any logic that lives in the NX Open program itself (as opposed to inside the called NX Open functions) is not redone — only the actions inside the called NX Open functions are replayed.
• If a lot of NX Open functions are executed, recording can consume significant time and memory. In some cases, redo may need to be disabled to save those resources.
• If an operation cannot be redone correctly by replaying NX Open functions alone, redo should be disabled — otherwise an attempted redo could invalidate data in the current session.
• Redo can be enabled or disabled with Session.EnableRedo.
• To exercise the redo capability at all, the NX Open program needs to be executed from the toolbar (the Redo button becomes available following the recorded operation).

Relationship to the Object Model's Builder/Commit Pattern

From the Common Object Model overview (objectModel.md): features and many other entities are created/edited through a Builder class. Builders expose methods (or .NET properties) to get/set the defining data for the entity, generally mirroring the corresponding UI command's input data. Call Commit to create the entity or apply the edits, and Destroy when finished with the builder. In practice, an UNDO Mark is typically set before constructing and committing a Builder, so that if Commit() (or subsequent validation) fails, the session can be cleanly rolled back with UndoToMark.

Related Topics

• Development Cycle Considerations
• Journals
• Compiling and linking Overview
• Editing expressions
• Common Object Model (objectModel.md)