Bug when moving features at "beginning of the body"

[galou_breizh]

PartDesign's function "move object after other object" is broken when selecting "Beginning of the body"

The error is
<code>
Traceback (most recent call last):
File "<string>", line 1, in <module>
<type 'exceptions.SystemError'>: Body: the feature we should insert relative to is not part of that body
</code>

The object gets kicked out of the body. I tried Datum Point, Datum Line, Datum Plane, Local CS, additive primitive, and pad from sketch.

By the way, shouldn't the text be rather "move feature after other feature"? "object" doesn't seem the right term in this context.

Thanks,
Gaël

OS: Ubuntu 18.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16033 (Git)
Build type: Release
Branch: master
Hash: 2b0d3477cb5700f5188be0ee5152e50ad6766e9c
Python version: 2.7.15rc1
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

[kisolre]

Same here:

Code: Select all

OS: Windows 8.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16028 (Git)
Build type: Release
Branch: master
Hash: 9079de7516eca945587e18f6076ec74eb7bd043c
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Bulgarian/Bulgaria (bg_BG)

And same with the oldest I have:

Code: Select all

OS: Windows 8.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15816 (Git)
Build type: Release
Branch: master
Hash: 7ee0e4d43909ec688299b8498b240cccf8362c47
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Bulgarian/Bulgaria (bg_BG)

[wmayer]

I could reproduce the incorrect behaviour and the reason for this is an invalid static_cast. It's now fixed with git commit 13433f4
But still you have to use this tool with care because it can easily happen to create cyclic dependencies.

Btw, a related issue has been discussed some years ago: https://forum.freecadweb.org/viewtopic.php?f=8&t=22876

[kisolre]

Something else I noticed after the pad was kicked out of the body - if I try to drag it again on to the body it gets added as basefeature which causes cyclic dependency:

CyclicDependency.JPG (166.1 KiB) Viewed 1560 times

[wmayer]

issue #3888

[wmayer]

Something else I noticed after the pad was kicked out of the body - if I try to drag it again on to the body it gets added as basefeature which causes cyclic dependency:

With my fix above the pad won't be kicked out any more. But it still can cause cyclic dependencies.
But it's also possible to manually drag a pad outside a body and when dragging it back it creates a base feature. I think this should be changed as usually the base feature is supposed to be used for non-PartDesign objects.
issue #3889

[NormandC]

@wmayer

Just FYI, the base feature can also be set indirectly to a separate Body which is very useful to make alternate parts based on a "master" body, so if you work on issue #3889 please do not remove this.

It is unfortunately not possible to do it directly (select existing Body, create new Body, you'll get a "Body can't be based on another body." error) because DeepSOIC disabled it, he was finding it too intrusive as it was easy to create it by accident.

[kisolre]

I think he means different actions for drag/drop depending on what is dragged - body,solid,PartWB part - create basefeature; PD feature, sketch - insert in body tree;... Or something similar...

[wmayer]

Just FYI, the base feature can also be set indirectly to a separate Body which is very useful to make alternate parts based on a "master" body, so if you work on issue #3889 please do not remove this.

A PD feature must belong to a body. If we have a body-less PD feature then it should be safe to just move it to the dragged body. Or did I miss something?

[NormandC]

Sorry for not being clear. Of course you are right. I was responding to this:

the base feature is supposed to be used for non-PartDesign objects.

The base feature can also be based on a PartDesign Body, although indirectly: an empty Body must be created first, then you need to set its "Base Feature" property to another Body. I wish for this behaviour to remain and not be removed by accident or otherwise.

While we're talking about base features, this reminds me that currently, 2D geometry from the Part workbench can be set as base feature for a Body when it should not be possible. A base feature should always be based on a single contiguous solid (that is, until the single body rule gets lifted). I'll create a report on the tracker when I get the chance.