I am trying to write a command which takes an object as input and creates a piece of geometry that is “attached” to that object via history. The command also allows the user to reselect the previously created geometry and modify it using new parameters. I am running into a problem with the latter half of my requirement.
When initially creating geometry I use RhinoDoc.Objects.Add to add it to the document with a history record.
When modifying the previously created geometry I use RhinoDoc.Objects.Replace so that my object retains it’s original ID, however, this breaks my previously created history.
I have found that if add a call to RhinoObject.SetCopyHistoryOnReplace(true) before calling RhinoDoc.Objects.Replace that my history will not break, however, it does introduce a new unintended behavior which I can not explain.
By using RhinoObject.SetCopyHistoryOnReplace(true) prior to RhinoDoc.Objects.Replace my history remains but now it seems as though the connection is bi-directional! Meaning that where as if I grabbed my geometry and moved it before I could expect that to break history, now it does not break history and in fact it snaps back to it’s original location.
I’m looking for some guidance here on how to properly use RhinoDoc.Objects.Replace without breaking history. Ideally the replace method would take a history record or something that I could update with new parameters as well.
If I understand correctly, you want to do something like the BlendCrv and BlendSrf commands, which both have Edit options. This capability is not currently available in RhinoCommon. You should be able to do this in C++, however.
My example is complex so let me break down the part of this that I am most concerned with:.
I create the cube and add it to the document using RhinoDoc.Objects.Add and supplying a history record which references the sphere. I can move my sphere and the cube follows like it’s supposed to. If I move my cube this will break history as I expect.
Next I run my command again and recreate my cube and replace the original cube by calling RhinoObject.SetCopyHistoryOnReplace(true) on the original cube and then RhinoDoc.Objects.Replace passing the new cube geometry. I can move my sphere and cube follows like it’s supposed to. If I try to move my cube now, history does not break and instead the cube snaps back to its original position because the Command.ReplayHistory method is executing.
Why would moving the cube at this point trigger history to replay instead of break?
So far so good! I don’t understand why this fixes my issue but it does seem to fix it.
I’m really trying to better understand how the Rhino history system works. Can you elaborate at all on why it’s necessary to call RhinoObject.SetCopyHistoryOnReplace(false) and why that strange behavior was happening when I was missing that call?