DC formulas change after importing multiple DC's

[94JZA80]

i'll do my best to explain to you exactly what's going on right in front of my eyes. first of all, when i import a W1D (a 1-door wall cabinet dynamic component i created) into my model, everything about it functions as it should (resizing, repositioning, and the door animation). naturally, its sub-components (left & right sides, top & bottom decks, back, shelves, etc.) all have references to the parent component, the W1D cabinet itself, in their formulas. for instance, the side_right sub-component's position X value = W1D!LenX-LenX.

now, when i import a second cabinet into the model, this time a W2D (a 2-door wall cabinet), some of its sub-component formulas change from "W2D!xxxxxx" to "W1D!xxxxxx". i've discovered that the formulas that remain unchanged during importation of the parent component belong to sub-components that are unique, while the formulas that do change belong to sub-components that are not unique. i also know for a fact that these "unique" sub-components do not become unique until the instant that the parent component is imported into the model. i know this b/c i created the W1D and W2D components from the same set of sub-components, and thus those sub-components share common names. for instance, the right sides of the W1D and the W2D cabinet are both named "side_right." that, in and of itself, would indicate that these sub-components are not unique, despite being part of two different cabinets, because they share the same exact name. fortunately, when i import the W2D cabinet into a model that already contains the W1D cabinet, W2D's "side_right" gets changed to "side_right#1," along with a number of other sub-components, as evidenced in the sketchup outliner window. but then why doesn't this happen for every W2D sub-component? why does "side_left" not get changed to "side_left#1" upon importation of the parent component, unlike most of the other W2D sub-components?

at the end of the day, it doesn't take much effort to right click on the W2D sub-components in question, make them unique, and then manually change the "W1D" references back to "W2D" in their formulas...but as you can imagine, if i have to do this with just about every new component i import, then the time and effort put into fixing those things starts to add up quickly.

so in summary, i guess my question is this: why aren't subsequently imported components getting ALL of their sub-components renamed with a suffix like "#1" to make them unique and differentiate them from previously imported components? please let me know if my verbiage is insufficient, and i'll try to upload some pictures to help visualize my dilemma.

TIA,
Eric

[pcmoor]

Hi

I believe the solution is to reference the sub-components or groups from xxxx!, wd1! or whatever! to parent!
use the generic term, then parent name does not matter

First I build a new component by clicking in the formula values then when happy change the references to the parent with the term parent

Philip

[94JZA80]

hmm...i had no idea you could do that. i'll give it a try tomorrow and let you know if it solves the problem.

[94JZA80]

well, at first glance, and after some preliminary testing, using the word "parent" in place of the actual parent entity's name to reference it in formulas has solved the problem of formulas unexpectedly changing on me...so thank you for that.

my follow-up question was going to be about the fact that, prior to using the "parent!" substitution, SketchUp was renaming all but one W2D sub-component upon importation...and i was under the impression that either all or none of them should get renamed upon importation of the parent component. but in an effort to confirm which sub-component was failing to get renamed, i was unable to duplicate the scenario (i don't want to prematurely call it an error if it isn't one)...that is, upon importing a W2D into a model that already contained a W1D, all of the W2D's sub-components got renamed this time around, making them unique and differentiating them from the W1D sub-components. in a way, its disappointing that i couldn't reproduce that scenario, b/c i'll never figure out why it was doing that before...sometimes i feel like SketchUp does some completely inexplicable things. i suppose they could be unsolved (or perhaps even yet-to-be-discovered) bugs, but they could equally be mistakes on my part...i guess i'll never know.

[94JZA80]

to follow up, after further testing of the above solution, using the word "parent" in place of the actual parent entity's name to reference it in formulas has not entirely solved the problem. while it does prevent the reference prefix (the portion before the "!", or the bold part of the following example reference: B1D!XXXX) from changing after subsequently importing another component, it does not prevent the reference suffix (the portion after the "!", or the bold part of the following example reference: B1D!XXXX) from changing after subsequently importing another component.

for instance, one of the base cabinets i've created (named "2DB") has a custom attribute named "e1_back_type," which determines whether the cabinet gets a standard recessed 1/4" back, a flush 1/2" back, or no back at all. yesterday, after having already imported a few other base cabinets into my model, i imported this 2DB into the model. right away i noticed broken references in some of its formulas. specifically, any references to the parent component's "e1_back_type" attribute got changed from "parent!e1_back_type" to "parent!back_type" upon importation. it was then that i realized that all the previously imported base cabinets used the name "back_type" (and not "e1_back_type") for the attribute that controls the type of cabinet back. still, i don't see why that should cause the "parent!e1_back_type" reference in my 2DB cabinet formulas to change to "parent!back_type."

that said, i don't expect anyone to fully understand what i just said without being able to import some of my components into a blank model/template and witness the changing formulas for yourselves. thus, you'll find three different base cabinets of mine available for download below:

SPH_B1D.skp
SPH_3DB_fixed.skp
SPH_B2D.skp

please remember, these have been saved as components, not as models, so you'll need to open a blank template or an existing empty model and manually import them into the model. i'd start by importing the B1D and the 3DB - then import the 2DB and note the incorrect formulas for the "back" and "back_seams" sub-components attributes. if you were to do the opposite (import the 2DB and then the B1D and 3DB), then the 2DB would probably be fine, and you'd probably find incorrect formulas in some of the B1D and 3DB attributes.

something else i noticed is that, when i import two of the exact same cabinet (component) one after the other, the 2nd one gets renamed to make it unique and differentiate it from the first, yet only some (not all) of its sub-components get renamed appropriately. for instance, if you import the above B1D into a blank template/model, and then import a 2nd B1D into that same model, you'll notice that only the parent component name and the drawer sub-component get renamed from "B1D" and "dwr_1" to B1D#1" and "dwr_1#." all the other sub-components fail to get renamed accordingly. why is this? why the heck would Sketchup not make all of a component's sub-components unique when it makes the parent component unique? similarly, why would all of a component's sub-components not become unique when i manually make the parent component unique? do i really have to right click on every one of a component's sub-components in the outliner window and manually make it unique every time i import more than one of a particular component into a model? that seems quite ridiculous and overly time-consuming.

in summary, my 2 main questions are now as follows:

1. why is the reference suffix (the portion after the "!", or the bold part of the following example reference: B1D!XXXX) changing upon importation into a model that already contains imported components? i.e. why do previously imported components affect the formulas in subsequently imported components?

2. why can't i import new components into a model and have them (and their sub-components) be truly unique right off the bat?

TIA,
Eric

[pcmoor]

Hi,

I believe the solution is to place all your cupboard units into one drawing. You can right click an offending (red ink) component and click redraw. I believe it should update without trying to reference a copy. you may have to repeat a few times, so all happy with each other
Then right click and save it back to your component folder

I did this with the three you posted and got them to be happy with each others existence without changing any attribute references

[94JZA80]

@pcmoor said:

Hi,

I believe the solution is to place all your cupboard units into one drawing. You can right click an offending (red ink) component and click redraw. I believe it should update without trying to reference a copy. you may have to repeat a few times, so all happy with each other
Then right click and save it back to your component folder

I did this with the three you posted and got them to be happy with each others existence without changing any attribute references

hmm...maybe i'm not fully understanding what you are suggesting i do, b/c it isn't working for me. let's just start w/ playing with 2 conflicting components instead of working with all 3 of the components i uploaded above.

if i import the B1D into a blank template, all is fine. if i subsequently import the B2D, i see red ink in its formulas right away, and red ink shows up in B1D formulas that had zero problems prior to importing the B2D. specifically, the B2D has red ink in the "Y," "LenY," "Hidden," and "thickness" attributes of the "back" sub-component, and in the "Hidden" attribute of the "back seams" sub-component. the B1D has red ink in the "LenY," "Hidden," and "thickness" attributes of the "back" sub-component, and in the "Hidden" attribute of the "back seams" sub-component. mind you, the red-inked B1D sub-component attributes have no broken references or syntax errors at this point, so why they're red-inked at all, i don't know...

ok, so now both the B1D and B2D components are in the model. if i redraw the B2D, nothing happens, and all the red-inked formulas in both the B1D and the B2D remain red-inked. if i redraw the B1D, all red ink disappears from the B1D's formulas (which makes sense since none of them were incorrect to begin with), and the red ink goes away from all but one of the B2D's formulas (which doesn't make sense b/c i can still see incorrect references in some of the B2D formulas that are no longer marked with red ink...that is, i see references to "parent!back_type" when i should see references to "parent!**e1_**back_type").

if, at this point, i redraw the B2D, all the red ink in both components' formulas reappears, as if i had just finished importing a B2D after a B1D, and i'm back to square 1. so it appears that no amount of redrawing either the B1D or the B2D gets rid of ALL red ink and makes the components "get along." can you tell if i'm doing anything differently than you did?

[pcmoor]

Hi

sorry, I changed the "e1_back_type" to "back_type" in B2D when I first tried to figure it out. forgot about it when I look at it again before posting

[94JZA80]

well the reason "e1_" is part of that's attribute's name is to control where the option appears in the component options window. with the exception of the predefined size attributes (LenX, LenY, & LenZ, which always appear at the top of the component options window), all other attributes, predefined or custom, get ordered alphabetically in the component options window. if i didn't care where the "back type" option showed up on the list of component options, i'd do away w/ the "e1_" prefix in the name.

but this still doesn't explain why my B2D's "e1_back_type" attribute name is changing to "back_type" upon importation after having imported another cabinet that actually has an attribute named "back_type"...i mean it does and it doesn't. obviously there's a link here, but it doesn't make any sense to me, and i feel like its happening in error.

likewise, the opposite is true - if i were to import the B2D first, i could open the component attribute window and see for myself that there is in fact an attribute named "e1_back_type"...and if i subsequently import a B1D (or any other cabinet with an attribute named "back_type"), all the instances of "back_type" in its formulas will change to "e1_back_type."