Can someone tell me why a dynamic component with its own set of attributes after it’s been imported into a model has all its attributes overwritten by another component of the same type but made unique? For example, I have a standard 5 piece frame and panel door with the parent being the door as a whole and the 5 parts being the children. I have attributes for all 5 parts to resize individually as the parent door size changes. When I import that door into a model with a cabinet, I link the width and height of the parent door to the dimensions of the cabinet and all 5 of the child door parts resize accordingly. So far pretty straightforward. Now I make the door along with all 5 of its parts unique and rename everything corresponding to the cabinet the door is on. Now comes the problem. When I import another of the same standard door into the model to use on another cabinet, all of the child component names as well as the standard attributes are overwritten with the ones from the original door, producing coding errors in the second door even though it is unique. WHY? This is terribly aggravating. Is there a way to prevent this?
not sure the exact cause here - i find making a DC unique is usually enough. and if i’m going to manually change it, i “un-DC” it (see Eneroth’s un-dc plugin – Eneroth De-DC-ify | SketchUp Extension Warehouse) then edit. then i import fresh from the source component directly and not the in-model list. as the in-model list may have the latest settings, whereas the source components will not (for me this is how it works).
I have tried Eneroth’s De-DC-ify, but I couldn’t get it to work. It installed fine, but just did nothing. And she never responded to help requests. Anyway, De-DC-ifying it defeats the whole purpose of using “reusable” dynamic components. I do not import from the in-model components list. I import from the original door file. Doesn’t matter, the code still gets overwritten. I think the problem is since the component is reusable, even though it’s made unique and re-named, it’s still the same component as far as the coding goes. Uniqueness may isolate it for manually changing things but apparently not for dynamic attributes. I have to go in and manually change all the attributes back to their original state, then code the door to the cabinet. It’s a huge waste of time. What would really be helpful is to have a way to make the child parts of DC’s like local variables in programming; they can have the same name but if they’re inside a unique parent then they’re isolated from all other children with the same name. It’s not that way in Sketchup. All child components are always global and are always tied to other child components of the same name even though they may be in completely unrelated parents. Sometimes you want certain components to all change together, but I find that to be the exception rather than the rule when it comes to reusable components.
If you change the formula of a child, you must first make it and its parent unique with the original present. Separating and changing then bringing them back together will cause the files to over write, the first one having the preference.
Always work from a base file for reuse of components
You can use instance names and Parent! to save repetitive work, But for size formula if there a change other than a parent reference, then you must create a unique parent and child.
If you upload a few of your doors can show how to do this
I follow what you’re saying. The problem is when you import, all the overwriting takes place as soon as you click to place it. You don’t have a chance to make it unique. What’s needed is an option to import a unique component. I’ve uploaded the door file. To repeat what I’m seeing, follow this sequence:
- Bring in the door via the import command
- Notice that the Make Unique command is grayed out for the first door.
- Change the name of the door and all the child parts by inserting the word “First” in front.
- Open the Component Attributes window and rename all the parts to match the outliner. Why Sketchup doesn’t automatically do this is beyond me. Notice that the code updates to reflect the new names. This is good for the first component.
- Import the same door again and click to place it and notice the child component names change to the first imported door. This is the beginning of the problem. Look at the Component Attributes for this door and notice the part names are the same as the original but the code references all point to the first door. Now if you change the part names, instead of updating the code it inserts the new name in with the first name and produces multiple errors.
This is unacceptable. What purpose does that serve? Because different cabinets have different attributes, not all the doors do the same things. The only thing I require is to change the width and heights of the doors with the exception of occasionally hiding or copying certain doors, so the child components need never be touched because their coding is already done thus making it reusable. The screenshot is an example of Sketchup butchering the child code by its nonsense inserting. The only way around all this is go through the code for every subsequent imported door and change all the code back to what it’s supposed to be in order for the door the function for any particular cabinet without affecting the others. This is a lot of extra work. I hope I’m making sense.
Shaker Door.skp (21.0 KB)
Copy the DC in the same file then that will give you the ability to make unique
If you change the Shaker Door! to parent! then reference is generic
If you need to change a formula, other than the parent title, then you need to make the parent and that part unique
I change the bottom rail formula after making unique to D1
use of parent generic name.skp (37.0 KB)
question: will you use opencutlist for takeoffs, as this will change the process
(a DC parent with a dc child will become unique after a change if it has another instance present)
I have used the parent! syntax in the past. Maybe I should use it more. Yes I do use OCL. This is partly the reason for all this as it will only work with components. I would rather work with groups as there are no naming restrictions and no cross-code contamination with them. I don’t suppose there’s a cutlist extension that works with groups is there?
I used the parent! syntax and so far it has prevented Sketchup from messing up the coding. But the original problem still persists. I have come to the conclusion that Sketchup went to great lengths to design the import function to make duplicates of the imported part, ie. it changes all the part names to the original, the coding from the original propagates to the newly imported component. From what I can see, the import function does a good job if all you want is exact copies of a component or if every imported component is completely non-generic. It’s possible to make generic components different from one another but it takes a lot of extra effort. For me, if I wanted just duplicates, I’d use the move tool in copy mode. Much easier. That seems to do the same thing as the import tool. That’s too bad. I was really hoping I could use it to import generic components and customize them for use in different scenarios, but it looks like I’ll be spending much time and effort fighting Sketchup’s tendency to make them all the same.
I generally avoid using dynamic subcomponents in my DCs, and use groups instead. So I avoid some of the proliferation of component definitions in the component browser and minimize the danger of “cross fertilization”.
My thought exactly. I would prefer to use groups but I also use OpenCutList which requires all components.
Import the door into a new model, copy it via the Move tool in copy mode. Then make the copy (parent and child parts) unique. Rename parts, then copy and paste into project model. This will keep everything intact and unique from any other instances of that door.
Hi @mdenbow,
OpenCutList consider only components for 3 main reasons :
- It doesn’t reinvent the wheel. We need a data structure that contains data shared with multiple instances of the same part. And a definition can offer that and it’s native in SketchUp
. - Sometimes its useful to group drawing elements that we don’t want the cutlist program consider as a part (walls or other environnement elements for exemple). One more time without reinventing anything the Group vs Component structure can do that.
- Without heavy computation, we can be sure that two instances of the same definition represent the same drawing part. We just need to check the material and transformation.
The old Cutlist 4.1 extension uses groups. But this brings a lot of limitations if we want to go further than just a cutlist program and add metadata like edge banding, tags, price, weight, etc … those data must be duplicated on each instances…
With definition everything is in one single place.