Understanding Cyclic Dependency errors

[ceremcem]

I want to create an object with PartDesign and I need external geometry constraints. That's why I need to create a Binder for the remote object under the (active) Body to be able to use the Binder within the Sketch.

If I create the Body (it will be created at document root), create the Binder (from an object that is inside an Assembly container), the binder is created under the Body. If I move the Body into the same Assembly container, "Cyclic dependency" error is thrown:

If move the Body into the Assembly container and then create the Binder, there are no errors thrown and further operations (external geometry constraint, etc.) work flawlessly:

What is the exact reason for that behavior? Is this a bug or a design decision?

[realthunder]

FC object have properties, like Placement, Shape, and stuff. Some of these properties are link property that points to other objects, because the owner object requires some other objects for computation, such as a Cut object requires a Base and a Tool object to compute the cut shape. In other word, Cut object depends on the Base and Tool object. A cyclic dependency means the Base or the Tool object somehow has a property directly or indirectly links back to the Cut object. That will cause all kinds of problems.

When shown in the tree view, a parent object is depending on all its child objects. But some dependencies are not shown as parent and child, such as the Sketch object and all its external geometries.

Binder by default uses the so called Relative Linking, in order to support cross coordinate space editing. It means, when you create a binder that binds to, say a box in an assembly, the binder's link property actually links to the assembly object, plus a subname reference for the object path leading to the box object. You can show the content of the link property using Python console, typing App.ActiveDocument.Binder.Support, it outputs a tuple(obj, subnames). So for a box in an assembly, the output may look like (<Part::FeaturePython>, [ "Parts.Box."]). So now you know why you have a cyclic dependency when you move the body inside this assembly. The child cannot have reference to its (grand)parent.

The correct way of doing this is to first move the body to the container, and then create the binder. If you want to move it later, you need to manually correct the binder reference after moving. The binder toolbar command will auto calculate the relative link before assigning reference. To make it safer to move, you can optionally set Binder's property BindMode to Detached before moving. You can also permanently switch the binder to Detached, If you don't want the binder to be linked to its bound object, but still want the shape for modeling. There is another mode, called Frozen, which retains the link, but does not update the shape on change. You can still manually update shape and placement by double clicking the binder.

[ceremcem]

To make it safer to move, you can optionally set Binder's property BindMode to Detached before moving.

That was a pre answer to a final question in my mind. Thanks :)

Binder by default uses the so called Relative Linking (...)

I think if we are capable of fixing such things by hand, "drag and drop" operation should be perfectly able to perform the required changes. So I assume this a bug of upstream.

[realthunder]

I think if we are capable of fixing such things by hand, "drag and drop" operation should be perfectly able to perform the required changes. So I assume this a bug of upstream.

SubShapeBinder is a feature I added. And you are right, drag and drop should be able to auto correct this in most cases. I'll implement this in the future.

[ceremcem]

SubShapeBinder is a feature I added.

Oh my!

And you are right, drag and drop should be able to auto correct this in most cases. I'll implement this in the future.

So I'm re-opening this one (assuming #75 will be resolved along with this one)?