I’ve noticed the following behavior.
If after starting Rhino a User creates a new document or opens an existing one, Rhino fires two undo events.
IsBeforeBeginRecording
BeginRecording
It then proceeds to ask the user to select a template/file. If the user cancels, we get the expected events to undo changes made in a cancelled command:
IsBeforeEndRecording
EndRecording
IsPurgeRecord
However if the user clicks through and creates/opens a document, we don’t get the IsBeforeEndRecording or EndRecording event.
It’s something that can be accounted for by watching for the close document event, which only happens if the user doesn’t cancel the action. But it feels different from every other time Rhino indicates that it’s starting to record, which is that we get the events telling us that it’s done recording.
The simplest way to for me to handle this is to make the assumption that if I see a document close event to assume that we’ve done with recording anything related to the document. Please let me know you see any potential issues with treating the document close event as a proxy for the IsBeforeEndRecording and EndRecording events.
Thanks for the report — your observation is correct, and it’s an asymmetry on our side rather than something you’re doing wrong.
Here’s what’s happening. When a modeless recording session is open (one that isn’t tied to a running command), starting a New or Open wipes the incoming document’s undo stack via an internal ClearUndoRecords() call. That teardown deletes the active undo record directly and simply flips the “recording active” flag off — it does not run the normal end-of-recording path, so the paired IsBeforeEndRecording / IsEndRecording events never fire. The IsBeforeBeginRecording / IsBeginRecording you saw were real; they just don’t get a matching close in that specific path.
So this is a bug — begin/end should be balanced. I’m logging it so we can fire the end events (or otherwise close the record cleanly) when the stack is cleared during New/Open.
In the meantime, your workaround is sound: treating the document-close (or New/Open) as the signal that the open recording session has been discarded is the right mental model, since that’s literally what’s happening internally. Just be aware the record is being discarded, not committed — so if you’re pairing state on Begin/End, you’ll want to reset it on close rather than treat it as a completed recording.
Thanks for the detailed report. I agree that the behavior is different from the usual undo-recording lifecycle.
I think treating the document close event as an indication that the recording associated with the document creation/open operation is complete is reasonable, provided it is scoped specifically to this New/Open document workflow.
The main potential issue I see is that a document close event does not necessarily mean that Rhino has semantically completed the same operation as “IsBeforeEndRecording” / “EndRecording”. A close event could occur for other reasons, and there may also be document-related operations during which undo recording is not actually being finalized.
Because of that, I would avoid treating the close event as a general replacement for “EndRecording”. Instead, I would use it as a fallback for this specific sequence:
If the normal “IsBeforeEndRecording” / “EndRecording” events arrive, use those as the authoritative completion signal. If the document-close event occurs without those events, it can then be used to clean up the corresponding recording state.
That approach should also avoid accidentally closing out an unrelated recording if Rhino later generates other document events.
So, in short, I don’t see a fundamental problem with using the close event as a fallback for this particular workflow, but I would recommend keeping it scoped to the recording/document state established by the preceding “BeginRecording”, rather than treating every document close as equivalent to “EndRecording”.