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.
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.
[_Delete
]_MatchSrf
The “[” prefix would execute the command while ignoring, but not changing, the state of _History _Lock. Similarly “]” would ignore the state of _History _Record.
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…
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.
@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?
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.
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.
Enables history recording for the following command.
For example: #ArcBlend
% (percent)
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
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 Enter
-Loft Pause -DodgeHistory _Record Yes Type=Loose Enter
%-MatchSrf Pause Pause Mode=Tangency Enter
-MatchSrf Pause Pause Mode=Tangency -DodgeHistory _Record No Enter
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.
_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.