Component name mismatching during component save

kamambers · February 23, 2021, 10:10am

I still don’t understand this “path theory” and why the SU Team is so strong in defending these “paths” that user has no idea about. I assume that it has historically arisen for some kind of need, but it is not universal and user-friendly enough.

I’ve shown enough examples before to see how this happens.

From my - user point of view, when executing the “Save As Local Collection” command, I choose the path of all files at once, but when executing “Save As …” - I choose it for each file separately. However, this still does not solve the root problem - in both cases, the file names given by the program DO NOT ALWAYS match the Definition names, which (I repeat) is the ONLY user-accessible, UNDERSTANDABLE and UNIQUE component identifier within a single skp file. In addition, in the batch process, the program does not even warn the user that instead of two or more files, a smaller number can be obtained, i.e. the program overwrites the files without warning.

ene_su · February 23, 2021, 10:24am

I’ve been a SketchUp user for about 13 years before starting working at SketchUp, and I am speaking as a user myself in this thread. As a SketchUp user I’ve relied on paths for many years in my own projects, and if I have, I am sure many other users have too.

The path can be seen in the Edit tab of the component panel, but could maybe be shown in Entity Info too to be more exposed.

ene_su · February 23, 2021, 10:37am

I think @Aroundthebend identified the root cause of the path issues a while back. When a component is made unique, both components are associated with the same file even if they are clearly different components.

I think this property is copied over to the new component along with all other properties, without this being thoroughly thought through.

kamambers · February 23, 2021, 12:42pm

Thank you for explanation! I probably understood where the essence of the problem lay. A small simplified example.

I have a file called Wall.skp.

When creating a new set of scenography, I put this file (wall template) in my project file (Walls.skp), multiply how many times I need it, then create each wall unique, give it a different height, width and surface texture, creating a door and window openings, naming these components Wall 1, Wall 2, etc., respectively.

Folder 1

In fact, none of the finished components correspond to the imported one. However, the location of the original file is still specified as the path for any of them, in this case all the same.

Panel 0 Panel 3

How does it help me? Absolutely nothing, because all the derived components are different from the original. At this point, when a component in a work file is changed (dimensions, textures, cuts, construction, etc.), its original source is for informational purposes only, no more.

Now begins the most interesting thing. When I run the “Save as local Collection” command, I only get one file named Wall.skp in the specified folder, i.e. no matter how different components I have in the model, a command overwrites one file over another with the same name without warning.

Folder 2

Only in the Components panel of the work file I can see the name I gave to this saved component.

Panel 2

Also by executing the command “Save As …” for all these new component files, the program offers the same name - “Wall.skp”.

You can imagine how much fun I have when it comes to finding a specific component to put in a Layout drawing from Component folder. Or I have to save each component (there are hundreds of them in the set of scenography) individually.

In my opinion, there is something wrong with the concept of components or their saving. If the file path of the original component is also saved (I don’t know when I should have used it), then the name of the original file name should not be used to save the components, but the name that each user can control - Definition name.

I still don’t understand why I should keep the original file name if I intentionally changed it in the working file. However, the original file is where it was and has not been changed. It can also be re-used as a template in other projects.

ene_su · February 23, 2021, 1:26pm

Thanks for explaining your workflow more detailed. I can absolutely see how this is an issue.

I’m thinking the Make Unique step is where the new components stop representing the same thing as the old one. Having SketchUp remove the path from the new definitions and not have multiple components pointing to the same file could solve this. If this was implemented, the Save As dialog could continue working as it does, without causing you this issue.

In other scenarios a user modify the component, but it’s still “the same” component, just a newer version of it, and then it makes sense to overwrite the same file when saving. This is why Save As defaults to the existing path.

TDahl · February 23, 2021, 1:39pm

I did not know this (bolded portion), thanks for the tip. I never use the Edit tab. I had thought that the saved path, though remembered by SketchUp, was invisible to the user. Displaying the path of a selected component in Entity Info would be interesting, but would be a trade-off with making the window a little bigger (which is not a good thing in general to me).

Yes, I find this very useful.

kamambers · February 23, 2021, 2:17pm

I do not think so. Maybe it’s possible to modify this command so that everyone is fine? For example, two commands instead of one:

Save component to original file (active only if there is outer path to component).
Save As a new file (with current Definition name).

TDahl · February 23, 2021, 2:34pm

In your work flow where the current Save As… behavior (defaulting to the existing known path) is not desired, was Make Unique used to create the definition of the component being saved? If so, I agree with earlier comments that the Make Unique operation should either clear the saved path completely, or at least clear the filename portion (perhaps keeping the device/directory portion).

In any case, where an existing component that has previously been subject to Save As… is being subjected again to Save As…, I do not want to have to select the full path and filename of the location in which the re-save should occur. This is the scenario I was commenting on when I said “yes, I find this very useful.”

RLGL · February 23, 2021, 2:48pm

This is something I could go for. At present I have several component files scattered for prototype parts and I am getting thoroughly confused as where each is and trying to keep them separated .

kamambers · February 23, 2021, 2:54pm

I understood, but our work habits are different. If I need to change the original component, I do it in the original file, not in a project. I see another potentially dangerous moment in the current order. This way, it’s not hard to accidentally permanently damage the original file and notice it too late. In this sense, the method offered by @Tig - to keep versions of the file with additional numbering - is more secure.

ene_su · February 23, 2021, 3:37pm

Personally I nearly always have one model that uses components and one that generates them. For instance I can have one model with a modular building, and one “library” model with all the possible modules organized in a grid. This allows for changing shared sub-components across all the linked components at once, e.g. change the kitchen unit across all the apartment modules. I rarely open the linked components individually.

booneyrex · February 24, 2021, 2:27pm

I have a question. Whenever I use the Right-click menu to Save As, it says XXX.skp already exits. So you want to replace it. So how does someone overwrite it without knowing.

booneyrex · February 24, 2021, 2:29pm

Sorry, I missed typed it says: Do you want to replace it.