@pcmoor said:

for doors use flip along axis instead of using a left and right component.

i understand the "flip along axis" concept you speak of, but i have no idea how to implement it in the sub-component of a dynamic component (such as the door on a dynamic cabinet). for instance, i'm currently using the latter method you mentioned (i have two door components, one left and one right, and the left door stays hidden when the cabinet is "hinged right," and vice versa). i would love instead to use a single door that can be hinged either left or right. but when i try to do that, i get door rotation and door location issues.

W1D.skp
above is a single door wall cabinet (designed by Exitenz) that i found in the 3D Warehouse, and it uses only a single door component that can be hinged left or right (as opposed to using two door components like i did, and keeping one of them hidden at any given time). the door position and rotation formulas make sense to me when i look at them in the component attributes window, but only if the door's component axes change when the hinging changes from left to right or from right to left. in other words, his door must work as hinged left and hinged right b/c it flips along an axis whenever the hinge selection is changed...and this is what i'm having trouble with. the only way i know how to perform such an action is to right-click on a selected component and use the "flip along component's red/green/blue" function. Exitenz's wall cabinet does this automatically when the hinging gets changed from right to left or vice versa...play with his model and see for yourself. anyways, the reason i get door position and rotation problems in my own model is b/c my door's component axes don't reposition (due to a flip along a particular axis) upon a change in door hinging. how do i go about this? here is my model so you can see what i've done so far:

W1D_one_door_swing_both_ways.skp

@pcmoor said:

for rotating function, you need to place an extra component wrapper to protect contents

i'm not entirely sure what you mean by this. are you saying that component that is meant to rotate (such as a cabinet door) must be a grandchild to the main component (the cabinet itself)? Exitenz's model above had a component wrapper <F_W1D> around the actual door component <DRBB#1>, making <DRBB#1> a grandchild of the actual cabinet <W1D>, and i don't quite understand why that's necessary...

@pcmoor said:

don't hide different types of doors,knobs or other components; swap them instead.

what do you mean by "swap them instead?" are we talking about the use of layers, or perhaps adding and/or removing parts from an external library into our model?

TIA,
Eric

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."

@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?

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

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.

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.

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

ok, after having finally come up with what i thought was a working solution, i realized that there is yet another hurdle to making a true 3-D door out of a 2-D generic door. whether i use the "follow me" tool to create the entire frame at once, or just to create individual members of the door frame (which is necessary if i start w/ the 2-D generic door), small polygonal surfaces tend to go missing on the corner pieces. i already have a thread that addresses and provides a solution this problem HERE. it turns out that the reason small surfaces go missing near the intersections of planes is because SketchUp deems them too small to render. the best working solution to this is to scale up the model (say 100x) before i extrude the frame or the individual frame members. this way, the small surfaces that would otherwise be missing if drawn at regular scale are now large enough to get rendered when i extrude the frame or its individual members. then its as simple as scaling it back down to original size and i get no missing surfaces.

the problem with starting with a generic 2-D door (w/ the formulas already built into the attributes of its sub-components) is that it doesn't scale up the way i need it to in order to create my 3-D corners without missing geometry. more specifically, while i can change the width and height of the generic frame no problem, it is designed to maintain the same frame width regardless of the overall size of the frame. in other words, if i take a generic 10" x 10" frame and scale it up to 100x, i'll end up with a 1000" x 1000" frame, but the frame width will stay the same and not scale along with the overall size change. now while that's ultimately how i want my doors to work in their finished state, i need the generic 2-D door's frame width to scale along with the increase in overall frame width and/or height in order to draw my corners without missing surfaces. but in order to do that i have to change the formulas of the generic door, thus defeating the purpose of having a generic door with all the formulas already built into it.

on the plus side, i decided to remove the "door thickness" attribute from my model b/c it isn't even an available option for the line of cabinetry i'm currently working on. b/c of this, each frame sub-component no longer has to be broken down into a fixed depth group and a variable depth group (this was necessary to prevent the frame profile from stretching along with any changes in overall door depth/thickness). thus each frame sub-component consists of only "position" and "size" attributes, and no longer contains 2 sub-groups, each with their own "position" and "size" attributes. this decreases the number of attribute formulas per frame sub-component (and thus the number of cut-n-pastes i have to perform) from 18 to 6. door construction now takes approx. only 1/3 the time it took me before...so not having a generic door with the forumlas built in isn't so much of a drag anymore b/c i only have to do 1/3 of the cutting and pasting i was doing before.

in summary, the inability of the generic door to scale its frame width along with any changes in overall door width or height prevents me from using it without generating missing surfaces in my geometry. and changing the formulas of the generic door to accommodate frame width scaling (thus allowing me to draw corners without missing surfaces) defeats the purpose of using it to create multiple doorstyles with the attribute formulas already programmed into it.

i'm not abandoning your ideas, i just need more time to wrap my head around them. in the mean time, i'm also considering rethinking my design methods...that is, instead of having a profile of the entire frame, i'll an [outer] edge profile and framing bead [inner edge] profile, since different combinations of edge profile, framing bead, and panel raise are what really make all the different door styles in the collection. i've got a roller coaster of thoughts running through my head right now, so i'll see where this takes me and update the thread later...

ok i finally figured out how you were doing it. ultimately it came down to making a copy of the frame profile first, and then edit copying it into the component rail or corner after having double-double clicked into edit mode. but it turns out that the way i was doing it before - cutting and pasting the excel formulas that defined each attribute of each component and sub-component line by line - is actually quicker for what i need to do. don't get me wrong, it is certainly convenient to take a scalable 2-D frame with basic attributes already defined and turn it into a 3-D frame without having to redefine all your attributes...but it turns out it'll only work well with a door design considerably less complex than the doors i'm programming. granted, i know you created it as a simple example and probably weren't expecting me to make great things with it. but i do appreciate you uploading it for me to download and play around with. i've saved it b/c it very well may come in handy for simpler door designs.

in the mean time, i'm in the midst of drawing several different doorstyles into sketchup, each with different combinations of edge profile, framing bead, and panel raise. despite the doorstyles themselves having different names to tell them apart, in the model space itself all doors use the name "door," all drawer fronts use the name "df," and all door or drawer front sub-components share common names as well. it would be so awesome if i could just copy the attributes section of an already completed door character for character in its entirety, and paste it into the attributes section of a newly created door in one (or very few) operation(s), instead of literally having to copy and paste it line by line...

thanks again,
Eric