Hi With regards ruby it would pay to post your enquiry in the developers' forum to get more responses Personally I am in a similar position, learning ruby, building DC to be used with code, interest is framing With regards swapping, and cut list consider the example again with a group of Right end components if you copy the side DC and replace the geometry within one of the Right ends with it, set the DC to required parameters, then right click, outer shell then explode, all updated and can be seen as complete in cut list Cheers Philip sides.skp

It's a matter of 6 of 1, half a dozen of the other. If the component files were saved as a component within a file then they wouldn't work properly when opened directly in your model, they would have a second top layer. A container within a container. It's not just dynamic components. If you select some geometry and save as a component, it will create a component that you can use happily via the component browser, but if you open the file itself it will be loose geometry. If you open an empty model and insert the component then save that model and upload it to the warehouse, it will then get a second coat if you download it again into another model. So you have a choice, one way you are over dressed the other way you are naked.

Oh. Just a flat panel, then. Not raised?

=ROUND(LenX/9,0)

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.

Hi Vigy, To make the holes, they are first contained within the surface then expanded to the edges, this makes the remaining surface act as one, and "self heals" as per attachment. Its probably best to build the mitre ends as 3 part component if you wish to use Dynamic Components At some point though your efforts may be best spent on the ruby code. Its fairly simple to move an edge to form the mitre using a script. I have considered your concept of engraving, which is to develop the hole further, attached is a reversed moulding to build a cutout in a panel. The biggest problem with DC's is that they soon become memory hungry and "clunky". Cheers for now still experimenting Philip PS after a weekend check the mitre box in wood working forum for update [image: Ik6x_Capture.JPG] making holes.skp insert2.skp

Edges can be hidden in solid components, just as well as other situations, if you want.

Wow, thanks very much goga, that's exactly what I needed!

Thanks Pcmoor for your respond, but I was referring to something else, Perhaps I didn't explain myself correctly, Sorry! besides I found a relative discussion where you do anticipate so I will continue there… Topic: Variable Rabbet and Dado Depth/Width for a Dynamic Component Thanks again! Vigy.

Thanks! I figured it was just something I was overlooking. Been doing similar interactions on a couple of models lately, and had that working on one set of doors but not the other. When I got the bad behavior to happen in a model of just a set of doors done from scratch, it really had me scratching my head.

i actually figured out my syntax error a few weeks ago, but thanks for the response. i also didn't get an email notifying me that you responded to my thread...i was just browsing the forums and noticed that someone had replied. i'll have to figure that one out so that i can get back to people when they post in my threads...

Thanks pcmoor

Start simple, create a rectangle, make it a component, "door" later you can replace it with any other component copy the door to make number required make all a component, then enter the component, make next set of doors a component but change the axis so that it is opposite to the parent do so until you reach last door, then in this case check to see if opposite if not then right click the axis when inside this door component and change build formulas as shown rotate about Z, opposite and reversed (90 x 2 = 180) x -1 I used the generic parent as the reference rather than component1 as suggested by Dave and others, etc, so easy to copy through. the rest are always opposite to component 2, so -parent!rotz works always check as you build, so see that it works... Then you can modify the door component. however its important you stay within the initial dimensions of the door boundary box. To increase its size, use scale tool on the whole (component1) So add the size changes to component 1, the children will follow, its not wise to have the children tell the parents what to do. Unless its necessary. [image: 6FLg_Capture.JPG] ![make a "door" component and copy 3 times](/uploads/imported_attachments/lcN7_Capture2.JPG "make a "door" component and copy 3 times") [image: zGnY_Capture3.JPG] [image: j66M_Capture4.JPG] [image: hAvE_Capture5.JPG] [image: j0yx_Capture6.JPG] ![we are considering rotation about Z, direct reference to"RotZ" as using negative](/uploads/imported_attachments/eQ9T_Capture7.JPG "we are considering rotation about Z, direct reference to"RotZ" as using negative") ![the second set needs to swing opposite first set, so "-" and 180degs =2x90](/uploads/imported_attachments/Rirq_Capture8.JPG "the second set needs to swing opposite first set, so "-" and 180degs =2x90") [image: zpkI_Capture9.JPG] [image: 4fWU_Capture10.JPG] [image: 5JvB_Capture11.JPG] [image: XUAC_Capture12.JPG]

PROBLEM SOLVED EVERYONE it turns out i didn't dig deep enough into the layers of parts used to compose the drawer boxes . For instance, the groups that comprised the middle drawer box component, dbox_2 (the left and right members, the front and back members, and the bottom), contained references to the top drawer box component, dbox_1. As soon as I changed all the "dbox_1" references to "dbox_2," the middle drawer box started resizing according to overall cabinet depth as it should. Obviously the same worked for the bottom drawer box, dbox_3. as you might have guessed, the reason the groups that comprise dbox_2 and dbox_3 had references to dbox_1 is b/c I created the middle and bottom drawer boxes by making copies of the top drawer box, dbox_1.

A simpler way would be to revert the Tools changes [you cannot be sure that the versions between 8 & 2013 are identical], then install the latest 'su_dynamiccomponents' set from the Extensions-Warehouse ? There are several plugins that used to ship with v8 Tools that you need to get from the EW and now appear in Plugins...

Hi Since you want to create an object that maintains two ends with variable distance between then split into four as you have drawn, the half cylinder ends as per attachment, the trick is to build cutting holes top, bottom and side, hide any lines not needed to be seen (outline of hole), add outlines or faces (e1,e2 you can delete these for your project) as required. See my models on warehouse...cylinder, pcmoor the rectangle sides should be no problem, hide the lines at the joins. The position of components can be tricky, but i let you give it ago, let us know if you need further help Cheers Philip half cylinder.skp

Could you upload the components so we can look at the problem?

It sounds like you are moving the cube away from the axis of the component. The bounding box normally hugs the component but if you move the cube or rotate it within the component then the bounding box will expand.

Hi Again Figured it out, place the two doors (with separate "on click") within a component, have the main door reference the wrapper or parent, thus if you pick the small door it rotates or the larger door the whole lot rotates Cheers gate3.skp

Hi By placing a component with hole cut both sides and a rim within a component wrapper one can place the door then explode the first wrapper which in turn activates both hole cutters attached solution which works after exploding, moreover have a look at the window opening for double leaf in my spot on the warehouse (pcmoor) updated opening to have size options cheers Philip insert bottom left, right click, explode