Ok, maybe I was not completely clear about this. I have a situation that describes your suggestion, that is, an object data model that contains data about the geometry in the document. This object data model is kept as a member variable on my plug-in.
Now, when the geometry in the document changes, this means that the object data model must change too. And, when the geometry change is undone, the object data model must change back. To that end I have used RhinoDoc.AddCustomUndoEvent(…) and a self-made undo stack that holds the undoable actions.
This means that each change to the geometry is accompanied by an undoable action being pushed onto my own undo stack. For this I typically use the Memento pattern to store the state of the object model. Now each memento is maybe a few kB in size, but when a user starts nudging like there is no tomorrow, these memento’s add up to a sizeable amount of memory.
On the Rhino side, the size of the undo stack is managed with the setting I mentioned in the first post. When many or large undoable actions are placed on the Rhino undo-stack, the stack is resized by removing items from the bottom of the stack.
What I would like to do is to somehow add memory pressure to the Rhino undo stack to reflect the size of my undo stack and, when undoable items are removed from the Rhino undo stack that have a counterpart in my own undo stack, to be able to remove the items in my own undo stack too.
Referring to the picture below, when “Rhino: Undo1” gets removed due to the Rhino undo stack growing too large, I want to be notified and also remove “My: Undo1” from my own undo stack.
I suppose that this would require an id to be returned when RhinoDoc.AddCustomUndoEvent is called and the creation of an additional event called e.g. RhinoDoc.CustomUndoEventDeleted where this id is exposed in the event arguments.