"Pause" Undo C++


I have used ClearUndoRecords before, but now I would like to “pause” Undo for certain operations. That means that I would like to stop recording Undo at one point, perform some functions (object transformations that would “clog” Undo), and that “turn Undo back on”. The point of this is that the operations before I “paused” Undo should still be in the Undo record. Is this possible?


Just read that you want to do this in the middle of the command. Dont know if that is possible… To do it with “complete” commands the next should work (under the line).

And found this that maybe could help you create a custom Undo Event:


I’m not familair with C++ but it is possible in VB.Net so than it should really be possible to do this in C++ :wink:

the code to do this in VB.Net is to have a handdler for UndoRedo and track if it starts recording and ends recording. Also Important to create a list of commands that UndoRedo should ingore else it wont record anything!:

    Private Sub UndoRedoCommand(ByVal sender As Object, ByVal e As Rhino.Commands.UndoRedoEventArgs)
        If e.IsBeginRecording Then
            If CommandsThatShouldBeIgnored.Contains(e.CommandId) = True Then
                RhinoDoc.ActiveDoc.UndoRecordingEnabled = False
            End If
        ElseIf e.IsEndRecording Then
            RhinoDoc.ActiveDoc.UndoRecordingEnabled = True
        End If
    End Sub

Hope this helps a bit or pushes you in the right direction.


Use CRhinoDoc::EnableUndoRecording(true/false) to enable or disable undo recording.

1 Like

Hi Dale…

Did that few hours ago…and for some reason it doesn`t work. For test purposes I did ClearUndoRecords(true); after every transformation and it works, no memory is lost (but I lose the previous actions that I want to keep)…but if I set EnableUndoRecording(false); before I do the transformations, nothing changes…no effect…memory is being lost with every move which means that Undo is not turned off… Is the value somehow somewhere automatically overriden?

The weird things is that without any Undo function (Clear or Enable), after I do the transformations of the selected objects:

( ON_SimpleArray<const CRhinoObject*> arrobjects; )

for(i=0;i< arrobjects.Count();i++)
xform.Translation( resvector );
context.m_doc.TransformObject( CRhinoObjRef(arrobjects[i]), xform, true, true, false );

if I press Undo Rhino says “Nothing to Undo”…although memory is obviously lost …I would say it has nothing to do with Undo and that it is some memory leak…but then, why does it stop loosing memory when I use ClearUndoRecords…?

What problem are you trying to solve?

I am making a (free) plug-in/tool that “explodes” a composition of objects…you select objects and then by moving a slider they move radially from the center of composition. That way you can have a better preview on it and it is a cool presentation effect.

This is very easy to make…just select the objects and with each slider move Transform (translate) the selected objects. The only problem I have is the memory leak…when I move the slider I can see the memory rising. When I put ClearUndoRecords after every slider move the memory leak stops - so the conclusion is that Undo is the problem. Since I would like the user to be able to Undo the things he did before starting my tool, I would like to “pause Undo”. EnableUndoRecording seemed like the perfect solution to me too…but for some reason it doesnt work. I put it at the beginning of the command, but it doesnt make any difference…I tried different variations and nothing…memory rises…only ClearUndoRecords works…


Have you considered using a display conduit to draw the objects you’re exploding, and once the user has accepted the new location of the objects, add the geometry to the document? An example of conduits being used in this way would be the “Line” command.

If you update the geometry that the conduit is displaying each time the user moves the slider, it shouldn’t use up the memory. This would avoid the need to pause undo, and if the user hits undo after the geometry is added to the document, it should revert to the position before the slider was moved.


thanks for the advice. The answer is yes, I did consider that. But honestly it takes less coding to do it without the conduit, and I am not sure if the “preview” looks the same as the original object. I think I will probably do it that way in the end, but it will take more programming…which could be avoided if EnableUndoRecording worked…

Stuart is correct. Dumping ground for transform after transform to simulate animation is not how the object table was designed to be used. You really should be a display conduit. Here is an example of you need one: