Boolean Operations Name linkage [Bug]

[TeancumQ]

Hi,
I have really enjoyed using your tool, I spent a long time trying to figure out why boolean operations wouldn't work on my solids though. It turns out that when you perform boolean operations your workbench code apparently uses the part label as input for selecting the object, this breaks whenever you change the part label. From the error it looks like it's only an issue with deleting the previous part, but the new part isn't formed either.

The following error is supplied, the new boolean is formed, and the objects are placed in it, but they will not visualize as objects. They can be pulled back out and done again, but this requires making 2 new parts and not renaming them in order for the boolean operation to succed.

File "C:\Users\QUISTE\AppData\Roaming\FreeCAD\Mod\GDML.\freecad\gdml\GDMLCommands.py", line 1580, in Activated
FreeCAD.ActiveDocument.removeObject(baseVol.Label)

Thank you for your help.

[KeithSloan]

Thanks for taking the time to report the problem.

So to clarify you have two GDML objects each in their own Part( vol in GDML terms) and you are trying to perform a boolean by selecting the two parts. If one or both of the parts the label has been changed, this produces an error.

Could I trouble you to provide a Report View of your experience.

Thanks

[TeancumQ]

Keith,
Below is what was listed in the report view. It won't let me upload a file, but i made one available on box at the provided link that exhibits the same problem. It's just a cylinder overlapping a box. I tested, and you can rename you GDML objects without issue. It is just that when you rename the part(vol) that the Boolean operations don't work. It seems as if it's getting confused and looking for the part that has a matching name with the internal label, when the external label has been changed. In my example i change the part name to parkbreak, (was supposed to be partbreak), and it can't find the object, because that is not what the internal name is. That is my assumption. This problem arises if the part name has been change for the tool or the base volume. The report below is for a cut, but the same issue happens using intersection or union. I hope this helps.

https://inlbox.box.com/s/xg52sp9o64ajnycc8f99f26q0it2psl6

[<App::Origin object>, Part::PartFeature]
18:13:20 base : Tube
18:13:20 base Placement Placement [Pos=(0,0,0), Yaw-Pitch-Roll=(0,0,0)]
18:13:20 Tool Vol : parkbreak
18:13:20 Tool Vol Placement Placement [Pos=(0,0,0), Yaw-Pitch-Roll=(0,0,0)]
18:13:20 tool Placement Placement [Pos=(0,0,0), Yaw-Pitch-Roll=(0,0,0)]
18:13:20 Tool : Box
18:13:20 Remove Base
18:13:20 Adjust Base Links
18:13:20 Remove Base Vol
18:13:20 Running the Python command 'BooleanCutCommand' failed:
Traceback (most recent call last):
File "C:\Users\QUISTE\AppData\Roaming\FreeCAD\Mod\GDML.\freecad\gdml\GDMLCommands.py", line 1581, in Activated
FreeCAD.ActiveDocument.removeObject(toolVol.Label)

No document object found with name 'parkbreak'

[KeithSloan]

I have a problem with my system at the moment so cannot test any changes.
I have looked at the code and tried to fix see branch 163fix.

I will try and resolve the problem on my Mac with FreeCAD.

You could try the branch or replacing the attached file but it is untested.

GDMLCommands.py

[TeancumQ]

Tried the new file, but got the same error when the final parts are removed. I did some debugging, and the problem is with lines
1580 FreeCAD.ActiveDocument.removeObject(baseVol.Label)
1581 FreeCAD.ActiveDocument.removeObject(toolVol.Label)
changing them to
FreeCAD.ActiveDocument.removeObject(baseVol.Name)
FreeCAD.ActiveDocument.removeObject(toolVol.Name)

solves the problem. The internal name of the object never changes after it is created, while the Label can be freely edited. I'm not sure If it is the lines

                    baseVol.removeObject(base)
                    print("Adjust Base Links")
                    base.adjustRelativeLinks(baseVol)
                    toolVol.removeObject(tool)

that changes the labels and breaks things, but that would be my assumption. Just changing the two lines above fixed the problem in both the original code, and the one you rewrote. Hope this helps.