Dodge History Prefix Request


It’s difficult to work with _History _Lock=Yes enabled. The general workflow is as follows:

  1. Create history enabled geometry with _Lock=Yes
  2. Save a version with full history
  3. Switch to _Lock=No to join surfaces and finalize the model
  4. Export geometry

Commands like _Delete are very troublesome and lead to button macros like the following:

_History _Lock=No _Enter
_History _Lock=Yes _Enter

This works well during the 1st step of the workflow, but unintentionally sets _Lock=Yes during the 3rd step. It also raises the question of whether the overt action of deleting should always override the implicit protection against accidental breaks in history.

It’s quite obvious that editing history should be allowed (now considered a bug) and most would agree that _Delete should override the lock state, but other commands are more subjective, i.e. _Rebuild, _Join, _Explode, _Trim, etc.

Feature Request:

Rhino has special command prefixes that alter behavior (* ! _ - ’ \ ~ ;). Two new prefixes can be added that solve all of the issues with this workflow by allowing users granular control over what commands override the setting of _Lock and _Record.


The “[” prefix would execute the command while ignoring, but not changing, the state of _History _Lock. Similarly “]” would ignore the state of _History _Record.

Hi Eric - for the Record part, this exists:

# to add history as a one-shot

% to suppress history as a one-shot.

I’ll see about the history lock one-shots - this seems reasonable to me…

@EricM - just to verify - the Lock override, what commands or cases other than Delete would you use this for? If Delete is the big one, then it might make more sense to simply allow (optionally or not) Delete to override locking and leave it at that.
Ah, ok, I see below - Rebuild…


Is that in V6? It’s not listed in the command prefixes:

They were missing in this topic. Added now, thanks.

I thought RH-56272 was for adding ‘]’ as a one-shot for lock children, but I see it was for adding the history one-shots to the scripting man page.

I will get a lot more use out of ]Delete, ]Rebuild, and ]Join, but %Copy and %MatchSrf will come in handy. Orient > Copy for history enabled duplicates and MatchSrf has problems which I need to submit in a separate thread.

@pascal there’s only a few that I want to always break history, i.e. Delete, Join, Explode, Rebuild, etc.

Overall it’s a quality of life thing working with Lock=Yes. Like it’s annoying the number of times per day I right click on history and clear lock children to run one command. Or the number of times I forget to flip it back. There’s no visual indicator. I personally rather see the state of Lock over Recording History in the bottom bar.

And I avoid HistoryPurge at all costs. My latest macro sets Lock=No, move 5, move -5, Lock=Yes. That way I break history but can undo to get history back.

I realized something today. Going to amend this request after Christmas.
This issue is added for one-shot locking/unlocking children.

@KelvinC Pascal showed me a few things and I’ve been playing with this. Trying to record a video to show you.

With the Record History field I’ve highlighted with the arrow, RMB brings up the menu.
What do you call it for the LMB that does a one shot dodge on next command? Is that accessible from the command line?



There is not a name for the action. It’s not scriptable either. What would you like to do with scripting it? Can you provide an example? Thanks.

You want to turn off History for the next command? In a macro it’s using a % in front of the command. You could make a button with


The percent sign turns off the history for the next command, and the backslash allows you to add the next command directly after the % so that history will be disabled.

# does the same for enabling history as a one-shot.

However, the actually LMB button click in the panel is actually a toggle. I do not see a way to toggle this setting as one-shot by itself via macro, only on or off.

1 Like


After using pascal’s tips I would like to change the request. This will be a lot more useful.
Instead of the prefix, please:

  • -dodgeRecord - The unnamed dodge record history function gets a name so it’s scriptable
  • -dodgeLock - nestable command that can be called before or during a command to one-shot dodge the lock setting
  • A visual status indicator that looks and functions like the Record History status bar.


@EricM, Thanks for sharing the screen recording. I added the Youtrack issues below.

RH-56397 History: Add a toggle command or option for Recording History

RH-56398 History: Add a toggle command or option for Locking Children

RH-56395 History: Add Lock children pane to status bar
The accessibility issue of the History pane menu that you mentioned in your screen recording above.

RH-56396 History: Pane menu is not accessible while a command is running
Based on your request change, can I mark RH-56344 obsolete?

1 Like

Absolutely. I think the revised requests will make the ‘Lock Workflow’ much easier for people to adopt.


RH-56396 is fixed in the latest WIP

I saw these get assigned to @GregArden (Hi Greg)

The youtrack descriptions for some of these are fairly vague. Plus I’ve spent another year working exclusively with _Lock=Yes, so I think it’s worth updating.

RH-56344 (1st Priority)

I told Kelvin this was a duplicated request, but I was wrong. Can this be marked active and given to Greg?

For the sake of consistency, we need one-shot dodge scripting prefixes for Locked Children to go with the existing “#” and “%” prefixes for Record History:

Special characters Meaning in macro
Enables history recording for the following command.
For example: #ArcBlend
Disables history recording for the following command.
For example: %ArcBlend
(open bracket)
Enables lock children for the following command.
For example: [Join
(close bracket)
Disables lock children for the following command.
For example: ]Delete

The exact char prefix doesn’t matter. The point is to have a complete set of modifiers to temporarily overrides the state of _Record and _Lock in _History without changing its state.

This is a top priority due to issues with commands that allow editing. Like_BlendCrv is broken again. It’s a very frustrating situation that’s permanently fixed by prepending it with a “]” prefix.

_BlendCrv _Edges //will never break history, _Lock setting irrelevant
_BlendCrv _Edit //by definition edits history, only works when _Lock=No

RH-56395 (2nd Priority)

I added the pertinent info from this thread.

RH-56397 and RH-56398 (Low Priority)

These would be useful, but the first two requests are way more important.

The idea is that if you forget to use a scripting prefix, you can still one-shot dodge _History’s settings via a nestable, named command. Again, DodgeHistory changes the state of the running command and not the state of _History.

Scripting Prefix Equivalent Nestable -DodgeHistory Command

#-Loft Pause Type=Loose

-Loft Pause -DodgeHistory _Record Yes
Type=Loose Enter
%-MatchSrf Pause Pause
Mode=Tangency Enter
-MatchSrf Pause Pause Mode=Tangency
-DodgeHistory _Record No Enter
[_Move 0 5,5,0 _Move 0 -DodgeHistory _Lock Yes 5,5,0
]_BlendCrv Edit _BlendCrv Edit -DodgeHistory _Lock No

RH-56344 is resubmitted to the developer.

I submitted a new bug report for fixing this problem in BlendCrv and BlendSrf. Thanks.

Thanks @KelvinC. Off the top of my head, _MoveExtractedIsocurve has the same issue with history being locked. I think there are 2 more. I’ll jot them down when I remember.

1 Like

_InterpcrvOnSrf is another one that can’t break history but Lock=Yes stops you from editing history.

I don’t know how long it takes to fix each of these, but adding RH-56344 would cover these issues and future proof new commands. Plus, it allows the user a preference over which commands should always break history.

For me, that’s overt commands like Delete, Join, and Rebuild. I use Lock to prevent accidents. I hated discovering that I broke History on something 20 minutes ago. And it saves a lot of time, letting you window select everything instead of searching for needles in the haystack.