Questions about fixing #2561 - Crash while moving part from one body to another

[poserge]

Hi,

I'm interested in fixing bug #2561 - Crash while moving part from one body to another|

First note actually fixes the crash but behavior is still not clear - if Box feature is selected and moved, Box's coordinate system stays in the old body. Or if Pad is moved, its Sketch stays in the old body.

Is this a bug or user should select coordinatesystems/sketches/other child objects as well?

P.S. I also tried to test Gui.runCommand("PartDesign_DuplicateSelection") command and it also shows non-stable behavior. I think general way of treating coordinate systems/supports and base objects is the same, so fixing Move command may help to fix the Duplicate command as well (if it is broken at all).

[ickby]

Hello,

the coordinate system must stay in the body. But this does mean that any links ti the CS must be replaced with links to the CS in the new body. For sketches it depends very much on context. Normally the sketch should be moved to the new body too. But what if the sketch is used already by annother feature. Than maybe making a copy? MAybe a shapebinder? IMHO this is something the user should decide on a popup dialog.

[DeepSOIC]

I feel there is some misunderstanding here. There are two things that can be referred to as "CS": origin features of bodies, and the attachable CoordinateSystem object that is in the tree under additive box feature.

[poserge]

I had attachable coordinate system in mind. Should they be moved with the box?

Right now all the objects except selected ones stay in original body. Even though coordinate system appears to be with box object all the time, it is still in the Model list of the original body. Same applies to sketch of the pad object - tree view tries to show proper hierarchy.

This issue rises too much questions actually. Everything can be reused by other features. Should all the dependencies be copied/instanced?

[DeepSOIC]

This is indeed a hard question. It feels like the CS has intimate relationship with the primitive, and should accompany it when moved, unconditionally. Geometry links across containers are real trouble makers, because you need to either include placements of containers or not include it. If you don't, that will probably result in a lot of unexpected behaviors, like "my CS is shown here, why is the box located there??". Yet if you do, aa circular dependency is introduced (Body depends on Box, Box depends on CS, CS depends on (inverse placement of) Body), which requires hacks to resolve.

[poserge]

I started to implement moving CoordinateSystem object along with the Primitive objects and I have two questions:

1. When Box moves along with its coordinate system to the other body CoordinateSystem object is still shown under the original body in the Tree view. If I save/open the scene everything looks fine, as well as when I touch/recompute. Tree view has its own way to decide who goes where and I could find exact place where it's happening.

2. I've made a box and I've picked XY_plane as a reference. Now I assume that box's location is controlled by the CoordinateSystem and CoordinateSystem's location is controlled by the XY_plane which sits in the BodyOrigin group. Do I understand correctly that when I enter some transformation in body's Placement (angle for example) I transform BodyOrigin too?
Now, when I move the box and its coordinatesystem from non-rotated body to the rotated body my box gets new body's rotation. And box's coordinatesystem still has non-rotated XY_plane in Support property. What am I missing here? Why box is rotated?

I understand that coordinate system can rely on other objects, but I decided to start somewhere and just move it with primitive. More functionality can be added along the way. In the end dialog with options sounds safe, but even in that case if user chooses to copy all reference objects, it can be huge.