Fix DefinitionList.load - problems in some situations


#21

This creates a new ComponentInstance. I want to be able to relod and relink any ComponentInstance.

Edit: Meant to say ComponentDefinition.


#22

I haven’t tried this myself, but have you tried something like:

component_instance_to_reload = Sketchup.active_model.entities[0] # put your instance here
new_definition = Sketchup.active_model.definitions.load '/path/to/file.skp'

Sketchup.active_model.entities.add_instance(new_definition, component_instance_to_reload.transformation)
Sketchup.active_model.entities.erase_entities(component_instance_to_reload)

… or have I misunderstood you?


#23

The issue is that when you have a loaded definition, it will contain its file path.
If you try to reload the same definition from the same path, then you will fail because each ‘external’ definition must have a unique path.

The way I’d side step it is…

Let’s say the definition.path is '/path/to/compo.skp’
It’s loaded as a definition named ‘compo’.
Check that a definition of that name exists and if so that it has a clashing path.
If no match is found by name / path, then you really ought to add another check in case the definition has been renamed, so we now must iterate all !internal? definitions, and look at the paths to spot a clash too…
Assuming that we have found a problem definition with a clashing path…
we do a definition.save_as(…) into a temp folder location, then immediately delete the temp skp that was made - it’s not needed any more.
Now that old_compo definition will no longer have the same path as the intended updated one, which we want to bring in next…
We rename the old_compo definition with some random / unique suffix.
We load the newer ‘/path/to/compo.skp’ and get a reference to the newer ‘compo’.
We then iterate all of the old_compo definition’s instances and replace their definitions in turn with the newer ‘compo’ definition.
The old_compo is now unused - so we use old_compo.entities.clear! [inside a model.start…commit_operation block to remove it from the definitions list].
Now the definitions list contains the newer ‘compo’ with the original name, and all previous instance refer to that - the older_compo is no more…

So we have mimicked the native reload context-menu item…


#24

Hi @TommyK

I just looked at this again in SU2017M2. I created a model with a component, exported it. Then I modified the exported model and attempted to load it back in. I now got a new definition.

I tested the same in SU2016 and it would not load the definition unless I touched the old definition.

Can you do me a favor and check your scenario again in SU2017?


#25

How? A simple change to the description text or something else trivial ?


#26

Anything that gives it a new GUID.


#27

Adding an entity (group/cpoint etc.)
I might be wrong about my SU2017 observations. I can no longer reproduce that. I must have tested wrong.

For some reasons I’ve yet to understand this happens only if the path is exactly the same as the one the component was saved to. Move it another location, or even rename the file and it loads it as a new definition.


#28

As I said last September !


#29

The path is saved as a property to the ComponentDefinition so it’s not that odd the old devs decided to compare it with the argument passed to load to see if it is already present in the model. However I would have preferred if it simply compared the GUID of the component with that of the external file.


#30

On My Mac, running SU2017, I get the same behaviour as stated before: I export a component, edit the exported component, and reload it through Ruby - the edited component is not loaded.

It works fine through the context click option: “Reload…”.

Tommy


#31

I’ve filed an issue for this in the API issue tracker, with my suggested implementation.