@unknownuser said:
There was a lot of debate about this before launch. We wanted DCs to follow the rules of SketchUp as much as possible. So the question became: "If I have 3 DCs in a model, and I scale one of them, should all of them update? Or should only the one I scaled?"
...In the end, we thought it would be more frustrating to have every instance in the model update instead of just the one you scaled.
We've talked about adding some kind of toggle that would allow you to choose which behavior you prefer. Any thoughts on that? Do you guys think we did it backwards? I'd love to hear your ideas.
No, you didn't do it backward or forward, you just didn't work it out at all. The only logical solution would be to scale the one DC WITHOUT BREAKING THE LINK TO THE ORIGINAL COMPONENT DEFINITION.
It is essential to design workflow to be able to go back and make changes to ALL elements throughout a project in a quick and centralized way. As budgets change, design options are accepted/rejected/marked up, and products enter or leave the market, the ability to edit a single entity and broadcast that change to all instances in the model could save hundreds of production hours.
I am actually really surprised to discover that this is how DC work and the whole scheme is actually intentional. I am not a programmer but I don't understand why this could not be fixed? User Defined attributes can already feed sub-entites data, like LenX for a certain sub-group can be set to the User Defined attribute "MyLength" so why should it matter if one DC has "MyLength" set to 20 when another is set to 30? I must be missing something here?
Revit and AutoCAD have this ability baked into Families and Dynamic Blocks already. The both use dimensional constraints and user-defined parameters to set the contextual "data" of an entity and objects within can be set to react to that context in different ways.
And I think a "Component Replacer" is more of a band-aid approach than an actual solution. If it could be written as a 3rd party script (I believe ThomThom already did), it would have to not just reset the definitions of all the bastardized components, it would have to note and re-create ALL of the attributes of every component in the model so that all the scaling, visibility, etc. of various components would not be lost in the re-writing.
Please tell me this has already been worked out in SU2017 or something and that is why there has been no further dialog on it!
