FreeCAD_assembly3
FreeCAD_assembly3 copied to clipboard
realthunder
inherited elements all get the same name
Consider a round bar is created and one of its ends is named 'bar-end'.
Make an assembly object and add two such bars. Examine elements and there will be two there both named 'bar-end'. Attempts to name them differently end up in broken links since the parent writes back any changes to child.
I would expect the parent to maintain its own list of element names and call these 'bar-end001' and 'bar-end002' , or some such. They could then be distinguished in the parent and potentially given other names if required.
this is not a major problem but is probably undesirable and may be worth considering changing.
Can you attach a picture showing the problem?
Attempts to name them differently end up in broken links since the parent writes back any changes to child.
Especially this part, what did you change to break the link?
Sorry, one detail missing from my report. I meant to say add an plane alignment on the two end faces and do the renaming on the elements of the constraint.
If I attempt an element rename in the parent it sticks first time ( what is less obvious is that it seems to apply this change to the child object ). If I change the second instance of the child, it also tries to rename in the child and thus breaks the first instance because its name no longer matches anything in the child. IRRC, both elements ended up showing a broken links in the parent.
How can I attach here?
well drag didn't seem to do much and clipboard on seems to paste the file name....
/tmp/twobar-collection.tar.gz
Looks like Windows only universe on github ( well considering who owns it ! )
I'll drop it into the forum. It's tarball of the current files I'm using for the SBR20 on beam work.
Yeah, windoze only universe, as I guessed. Looks like they can't handle more than one dot in a filename. :(
I've dropped my archive on the "constraining and edge" topic on the forum. With notes about the elements concerned.
Ah, I see. I didn't expect this problem. But how did you break the links? Which label did you change? By right, label change by user is automatically tracked.
The names are the same because that are in fact referring to the exact same sub-object. A Link does not create new sub-objects. Think it as a symlink on Linux. When you create two symlinks to the same directory, and rename a file inside one of the symlink. The file in the other symlink will change as expected.
There are a few ways to help you distinguish the two,
- Treeview mouse over highlight gives the visual clue, although it won't help if the two elements overlap
- Select one element in treeview and click Go to relation button, or use keyboard shortcut (A, R) to find out which part owns the element. Note that there is a bug in this function which I just fixed. Please sync my asm3 repo.
- There is a second column in treeview, just beside the object label. You can add any note inside for your own purpose. Just click and press
F2.
But how did you break the links?
IIRC, the default names were something like ElementLink004 and ElementLink005. I first renamed the constraint, then changed the uppermost element label. As I wrote this was accepted ( I did not realise it was affecting the underlying object, so did not look to see any effects there ).
I then clicked and hit F2 on the second element gave it a different name. Initially that seemed to have registered. I hit the Save icon and it gave the message about updating dependent files, which I OK'ed. To my recollection that is when I got the exclamation marks and the hover message then showed "broken link".
It is a little misleading that the default names are different. The default names seem to be local to the parent's constraint item but cannot manually be entered as different. There seems to be a logical design error here. What is logically needed at this level, is what the interface does by default, independent names. There seems to be different treatment depending upon whether the child has a default or user defined element name. I think this points to a fundamental design oversight which may require a more flexible solution.
Thanks for your workaround solution with the secondary field, that's noted.
