First: DCs are an extension, they are not built on the native code, so there is considerable disconnect. However, there are work arounds.
Any exposed custom attribute in the parent will cause this effect on collections, however the info attributes will update independently.
If the item is placed one level down, with the parent used as a vehicle or shield, the attributes will not be over-ridded with a value. With your example, seems overworked, which need to be (scale definition, check rotation) then componentize, then can change the length.
PROVE.skp (60.4 KB)
Consider a different approach, DCs work within the boundary box of the object(s), so objects at the boundary with axis inward will maintain their position, fix sizes maybe required. If an object has hidden boundary line(s) then its size can be maintained with a distance from the end of the hidden line.
DCs can be reused if they are totally made unique, use Eneroth’s “deep make unique” directly after copying. (very important)
Start with basic cuboid, for beams, columns, one dimension scaling, set up with hidden “axis” and shape one level down. Any DC with a DC child will update automatically whereas a lone DC with no DC children requires Redraw to update.
Scaling is important, so for one dimensional DCs always start with same (1m) length or make sure all parts are at scale=1
Rotation should be avoided initially, then should be isolated if more than one axis. so, a column can be a beam, but parent is rotated
Compared to the native report writer, the advantages of using OCL (opencutlist extension) is very high, so best to build items with length on X-axis, etc…
another point is not to use ‘Name" attribute but activate the instance name, this updates the option and entities dialogs. With changes in the latest OCL, can "read’’ DC attributes
PROVE 2.skp (35.4 KB)