Component name mismatching during component save

Do the definition names given by my snippet in the RC match those in the exported subfolder ?
By ‘incorrect names’ what do you mean e.g. XXX#1 becomes XXX_1, because # is best avoided in SKP file names…
What are the names of the ‘lost’ ones ?
At the moment if you have a definition named XXX#1 and another named XXX_1 they’ll both become XXX_ due to the ‘safe-naming’ tool…
As much info as you can give will help fix theis…
However I can sidestep that…
I’ll look into publishing an update shortly…

TIG-DefnSaver.rb (3.7 KB)
This v1.1 checks for existing SKPs in a collection subfolder and increments the end of the name to avoid overwriting…
So if you have definitions named XXX#1 and XXX_1 previously they’d both get SKPs named XXX_1.skp and so the later one would overwrite the older one, with v1.1 if XXX#1 is saved as XXX_1.skp now when it’s the turn of XXX_1 it’s renamed XXX_2.skp to avoid the overwriting issue…
This clash of exported names can be avoided by using definitions naming so that if the SKP’s name is ‘fixed’, e.g. to replace a : or # with _ - then duplicated SKPs are never produced when making a collection…

1 Like

Thanks, @Tig, sorry for the late reply! Your plugin was fine with component names. I think the problem is probably with the file itself, because files with a simpler structure don’t have a problem saving all components with their definition names, but the latest version of the plugin doesn’t work for that file either.

I wrote about the shortcomings of the native command at the beginning of this topic. This is exactly what happens when I use it: components disappear (apparently overwritten), some components are given old names.

Sorry - I’ve rewritten the RB because you found it contained a typo, here it is again: TIG-DefnSaver.rb (3.7 KB)
v1.2

As I explained in our recent PM, it works fine for me with your example SKP, despite it being full of definitions with accented characters in their names ! There’s no need for my code to ‘fix’ any naming at all, and the definition-name matches the exported SKP-name perfectly…

So back to your issue ??
Are you saving to an empty new subfolder so there’s no ‘duplication’ ?
Are you saving locally - rather than to a network drive or drop-box etc ??

Thanks, I installed the latest version of the plugin. Now everything from the context menu works, but still does not work from the File menu.

Usually I save components to an empty new subfolder, but in exceptional cases I add them to an existing collection. But only if I’m 100% sure the file names won’t duplicate. I do this if the model of one project is divided into several files (for example, carcasses, coating, etc.). But this is very rare.

I usually work with local files because it’s more versatile for me. I only save copies of local files on the external HDD, Dropbox, and Trimble Connect. Once the project is complete, I may make some edits without making a local copy. However, I understand that this may cause problems, and if they do, I will make a local copy.

P.S. I have never had a problem using accented characters inside SU. As I wrote earlier, only the comma, which is the decimal separator in my country, is converted to an underline in the file names, which is perfectly acceptable to me.

Here’s v1.3 TIG-DefnSaver.rb (3.8 KB)
I corrected a typo in the File-menu entry… it now works the same as the context-menu entry…

Yes, all options now work.

Oh, it’s as funny as a plugin renaming files!

Renamed

In fact, this is not the best offer, because my file names consist of dimensions, product articles, numbered parts. This changes what doesn’t need to be changed. I would rather have duplicates marked as, for example, in Windows: (1); (2) etc. or in a similar manner, but without changing the letters and numbers in the existing name.
If, however, this is the only way to regulate it…

Of course it’s possible to name otherwise duplicated SKP names from XX to XX (1), XX (2) etc, but the example model you gave me by PM contains nothing needing that solution anyway…

My Latvian is not so good… but…

Your SKP list now shows duplicates e.g.
ārsiena kreisā mala.skp AND ārsiena kreisā malb.skp
so there the ending has been incremented from a to b, I can see how this occurs when there’s already a matching SKP in the selected export-folder !
The attached update v1.4 now avoids this duplication by adding an incrementing suffix [like Windows file-copy] so ārsiena kreisā mala.skp is duplicated as ārsiena kreisā mala (1).skp and if that also exists ārsiena kreisā mala (2).skp and so on…
TIG-DefnSaver.rb (3.9 KB)

Es ceru, ka tas tagad atrisinās jūsu problēmu …

2 Likes

Thanks, @TIG!

Like my English. :rofl:

a and b are not the biggest misfortunes in this file. For example, parts PD 70 and PD 71 are very different (not in this project) and it would not be nice if the manufacturer ordered the wrong part based on its name.

PD

Yes, the last change is definitely better. HAFELE 237.55.140 (1) is a much more appropriate name than HAFELE 237.55.141, which represents a slightly different product.

HAFELE

Thanks all for the discussion here, and others like it on these forums and on the Beta forums. I’m working to collect the requirements to solve these problems.

@kamambers @LEGOsketcher regarding the Save As workflows for unique components, it’s apparent we missed an important use case (a long time ago). We’re working to get things working in the way you’ve asked.

@kamambers thanks for broadening the discussion to include use cases related to saving entire collections. The discussion here is very helpful for seeing and appreciating the relationships between saving out individual components, as well as saving out entire folders of components.

@TIG thanks VERY much for your effort to script a solution to these! The edge cases you’ve worked through here regarding special characters and incrementing are things we easily could have stumbled on. I’m consistently humbled by your willingness and ability to put your wizardry to use to help users overcome our blunders.

Thanks too @Aroundthebend for the summary you offered, and for articulating Item #3 in that list, which is another thing that has come up in other discussions, and is something else we’ll be taking a look at.

If any of you have any sample files you’re able/willing to send my way, please do.

@colin @Mark @ene_su

4 Likes

Thanks, @MikeTadros! I hope that you will be able to find a solution to this sore problem soon.

1 Like

What do you mean by “Save as local collection”? Is this the drag and drop operation between the two component browsers?

The way SketchUp is designed, the component name and component path are two different properties. While I can see why you want to use the component name when “Saving as local collection”, there are also use cases where it makes sense to keep these separate.

I only use right click > Save As when saving out components, and would absolutely not want this to change the path based on the component name. I already have set up the component to link a specific file and want to keep that connection. Breaking this connection in this scenario would be akin to File > Save not overwriting the open file, but make up a new path based on the Model name property set in Model Info.

However, it is entirely possible the two UIs warrant different behavior. The UI I use (Save As) is based around file paths, but the component browser libraries follows something of a different logic. Here the paths aren’t as clearly exposed, and the component name is the primary way of identifying a component. In this UI it could make sense to ignore the already associated path, and make up a new file name based on component name.

Typically, this problem derives from the fact that SketchUp is basically a ‘one man show’ and works ok when creating components and saving them.
Woes and hard-to-follow-workarounds are needed when trying to rename them in the OS or SketchUp, for that matter.
The team really should address a more ‘company’-friendly workflow, where other’s might rename components based on some new insights etc.

1 Like

Save as Local

I really do not understand why it is necessary to repeat stubbornly that there are other ways, which are not suitable for my work, to achieve the same in a much more complicated way that the program “seems to offer” much more easily. As a user, I don’t care why there is a discrepancy between the promised and the actual result.

Again, “Save as Local Collection” means that each item in the collection is saved in a separate file with its unique name (for me as a user, “name” means only what I type in the appropriate field, i.e. the Definition). In reality, there are enough situations when the obtained result does not meet expectations, not only when creating files with inappropriate names, but also losing them (because one component replaces another in the saving process). Please go carefully to what @Tig said! He has solved this problem. It would be good if his solution was integrated in the next program update where it should be, and not as a separate plugin. If not already done.

I haven’t told you to use SketchUp another way than you are already doing. I’m sorry if I was unclear.

I’m trying to come up with a way to fix this for your specific way of using SketchUp, without breaking it for other users. In other situations users rely on the component path.

I’m proposing implementing your suggested changes, but specific to ‘Save as local collection…’. Here I agree it makes little sense to rely on the old filename for individual files, as you select a directory anew. When you on the other hand right click an individual component and select Save As, I think it should default to the path the component is already associated with, as other users rely on this.

Thanks, Christina, for the answer! Maybe I really misunderstood something.

However, I do not agree that arranging the preservation of a collection will upset other users. In the situation you describe (right button, Save As …), the exact same thing happens that when you use the “Save as Local Collection” command, you may be prompted to save the file with an incorrect name. Unlike the “Save as Local Collection” batch process, you can change the every name in this situation. However, it is very tedious to keep all the components of a project in this way, if the number of components is measured in hundreds.

I’m thinking “Save as local collection…” is a special case as it involves multiple components. Using the old file name for files that have one, while at the same time making up new file names for files without, makes little sense to me here. Re-using the old file name makes even less sense when you are also changing the directory, and clearly aren’t trying to save over the old file.

However, in the case of saving out files on individual basis, having Save As suggest a file name other than that the component is already associated with could break workflows. If you have set up a file structure for your project and save and load components across multiple models to and from the same files, you don’t want the path to change, unless you explicitly chose a new path.

I think it’s important to remember people use SketchUp in different ways. In one project the component named “IKEA KALLAX Shelf White 77 x 147 cm” could link to “IKEA KALLAX Shelf White 77 x 147 cm.skp”, in another to “IKEA_KALLAX_Shelf_White_77_x_147_cm.skp”, in a third “ikea_kallax_shelf_white_77_x_147_cm.skp” and in a forth “IKEA/802.758.87.skp”.

No matter how someone uses SketchUp, we’re talking about a feature that offers to save a collection of components from one file. The only unique component identifier available to any user (neither a programmer nor a program developer) is the component Definition name, which can be created by user, modified, derived as unique, and so on. I ask again - why is this existing unique identifier not used in all cases available to any user?

Or rather, Save as Local Collection works 95% of the time, as expected, and no one has any problems with it. Why doesn’t this happen in all 100% of cases?

I am not convinced by the example of the IKEA shelf. Even if it is the same component, no one will suffer from it being named differently in each file and saved from that file with its own unique Definition name.

I Agree. Most of the time, components come from different locations. Filepaths often refer to non-existing or lost filelocations ( I have made hundreds of components where the filepath is a laptop that my daughter now uses)
It’s still there residing, even when shared by 3D Warehouse etc.

The ‘save collection as’ should reconfigure this IMO

1 Like

I agree about Save as local collection, but not about Save As.

The path is accessible to users, by loading the component from that path or saving it to that path. If you save out a component to “IKEA/802.758.87.skp”, change it, and save it out again (not the whole collection, but that individual component), your file structure would break if SketchUp made up a new file name from your component name.

I think it is entirely possible to tweak Save as collection, without breaking Save As.