Bug: moving copied component moves original too

[edkman]

After copying a component (<CTRL> drag and drop onto project) and rotating it 180 degrees, and then initially moving it into position, I found that now moving it causes the original one to move, but in the opposite direction (which is the same direction in its component co-ordinate system).

It looks like perhaps the transform is partially shared between them, so that the second one is not actually a fully independent instance.

There are no joints involved.

https://screencast.autodesk.com/main/details/a6cf881a-9aa7-4d87-9f71-096308383cf1

[SallyYang]

CTRL+Drag and Copy & Paste component can only get component duplicated, however the body under the component will share the same instance. You can add more features like filter, hole to validate if both bodies under the different components changed accordingly. If you want to get an independent body, you have to use Copy & Paste New commands.

[edkman]

ohhhhhh...

...the Move popup shows me (now that I know) that it had selected the Body, not the Component, and then what you say makes sense.

This is a VERY subtle difference from a user point of view, having made no conscious selection of whether the Move was going to be of a Body or of a Component.

While I will now pay much closer attention to that distinction on Moves, I do consider that the lack of any visual clue (that I can disern) as to whether I am selecting and moving a Component or a Body means that there need to be some changes.

For example, if more than the one Body will be Moved, all of them should be highlighted simultaneously, and have the Move arrows and handles applied to them, so that it's very obvious that all of them will be affected.

Also, the conext menu popup that I used to select Move with should indicate "Move Component" or Move Body" or "Move Face".

HOWEVER:

Looking at the Components and Bodies listed in the 

Browser, each has its own Body, so something else seems to be happening. Or else what you are saying is that even though it looks like it has its own Body, it's invisibly sharing something, which would be another entire problem with the program and UI.

[jeff_strater]

Thanks, Sally.  Yes, the problem you are seeing is because the Move command defaults to "Move Bodies, Sketches..." as the Object setting:

This will move the bodies within the components (that is, relative to the component's origin).  Moving the body will move it in all instances of that component.  Instead, if you choose "Move Components" as the Object input to Move:

then only the selected instance of the component will move..

Jeff Strater (Fusion development)

[edkman]

Yes, I can move just the one Component now that I know about that.

But how can one tell when one is about to move a Body that happens to be shared, by accident?

Both copies of the Component show a Body.

How does one tell that the two Bodies are in fact one instance?

How does one know, when <CTRL>-dragging and dropping the Component in the Browser, that one is not actally doing a deep copy of that component, but a shallow copy?

Is this all documented somewhere? I searched the Help. I may be using the wrong search terms: "drag ctrl copy component"

[jeff_strater · Accepted solution]

Agreed, that some of this can be confusing.

The answer is that components are the only things that can be instanced.  Instanced components always share all their data (bodies, sketches, work geometry).  we show that in the browser to help indicate that the components do, in fact, that own these geometries, and you can select, for instance, the body, by selecting it in any of that component's instances.

You can tell that a component is an instance by just looking at its name in the browser.  Component names have the form of "ComponentName:InstanceNumber".  In this picture, the component indicated has a name of "Component1", and an instance nubmer of "1".  

The only way to do a deep copy today is via "Paste New".  Paste New will create a copy of the selected component.  That component will get a new name:

hope this helps a little bit.

Jeff

[edkman]

Wow, I had no idea all that was so significant. My mental model of the project and its components is now very greatly changed.

Thank you for your example and explanation.

My component names were very long, for one thing. The 1:1, 1:2 etc. did not show up unless I hovered over them. Perhaps they should be elided in the middle to ensure the trailing information is always visible.

It makes perfect sense that a dragged and dropped copy of a component should be a reference, not a deep copy. And it make sense that modifying one instance of it should modify the other instances.

So I think my problem came about because although those things are quite good and justifiable, and it's even a good thing that I didn't actually even need to know those details or think about them before ran into this situation, there was nothing that I could see that gave me even a clue as to why the other instance was moving in the opposite direction from the one I was manipulating.

For me, at that moment, the result of the move violated the Principle of Least Surprise/Astonishment.

So, I think it may be helpful to do as I suggested in an earlier message, and do e.g. half-intensity highlighting of all other instances of a body when one of them is selected, implying that somethig done to one will affect the others.

Doing the same thing with the Move (or pull, etc.) handles will reinforce the fact that more things will be affected than are perhaps intended.

[dave]

Hugely helpful to me too.  Wish I had known this before I started copying and pasting a bajjilion things here.