Session, Undo Marks, and Update Manager Pitfalls in NXOpen

Practical, forum-sourced guidance on a recurring source of bugs in custom NXOpen applications: mismanaging undo marks and the Update Manager.

Undo marks are not optional bookkeeping

Every NXOpen operation that changes the model should be wrapped in an explicit undo mark. The typical pattern discussed across NX programming references and reproduced in community write-ups (e.g. designautomationlife.com's C# getting-started guide) is:

Session.UndoMarkId markId = theSession.SetUndoMark(
    Session.MarkVisibility.Visible, "Operation Name");

try
{
    // ... do work ...
    theSession.UpdateManager.DoUpdate(markId);
}
catch (Exception)
{
    theSession.UndoToMark(markId, "Operation Name");
    throw;
}

If NX encounters an error inside DoUpdate(), the system automatically rolls back to the undo mark passed into that call — so the mark you supply to DoUpdate matters, not just the one you set at the start.

Deleting marks: DeleteUndoMark vs UndoToMark

A common mistake is calling the wrong delete/undo API and unintentionally wiping out undo marks created after the one you meant to clean up. If you only want to discard a single mark without disturbing marks created later, use DeleteUndoMark — not a broader undo/rollback call. Conflating "delete this one mark" with "roll everything back to this mark" is a repeated source of confusing behavior in custom tools.

Redo has a memory cost

Redo is enabled by default in NX. For memory-intensive NXOpen programs (e.g., batch processing many parts, or generating large amounts of geometry), disabling redo before the operation and restoring it afterward is a documented optimization. One nuance worth remembering: if you re-enable redo after having disabled it, that must be done immediately before setting an undo mark — redo is not supported for "visible" marks that were set while redo was disabled.

Task environments clean up their own marks

Session.BeginTaskEnvironment establishes a task environment, and there is a corresponding method that deletes all undo marks created since entering it. Calling that cleanup method when NX is not currently in a task environment throws an exception — so task-environment-scoped undo cleanup code must be paired carefully with the Begin/End calls, not called unconditionally in a finally block.

Practical takeaway

• Always set an undo mark before mutating the model, and pass that mark to DoUpdate.
• Wrap risky operations in try/catch and roll back to the mark on failure so users aren't left with half-applied changes.
• Use DeleteUndoMark (not a generic undo call) when you just want to tidy up your own mark.
• Be deliberate about redo state in performance-sensitive batch tools.