Parent instance of a component

voljanko

Hello.
I have a subcomponent in a component instance and trying to have a handle on a parent of the subcomponent.But if I do the
subcomponent.parent , I have a handle on a component definition.But I want the handle on a right component instance.

How to do that?

Aerilius

I'm not sure if that's at all possible. A component instance refers always to a component definition and the definition contains all geometry and sub-components. When you are modifying entities in a component, you are doing this with the component definition (ComponentInstance.definition.entities).
If you try subComponent.parent, you get always the definition.
So it's never clear which instance the parent of the sub-component is, because the definition could be used by many instances.

The question makes sense if you have exactly one instance (one parent) but you don't have a handle yet:
parentInstance = subComponent.parent.instances[0]

voljanko

This is kind of a strange,because each instance can have different name ,attributes,ID ...
Mostly I'm interested in changing attributes,but I need to know to "who"

Dan Rathbun

@aerilius said:

The question makes sense if you have exactly one instance (one parent) but you don't have a handle yet:
parentInstance = subComponent.parent.instances[0]

I think this (above) is wrong.

subComponentInstance.parent
would return subComponentDefinition

.. and so:

subComponentInstance.parent.instances[0]
.. and
subComponentDefinition.instances[0]
would return subComponentInstance, not parentInstance

.. for the situation where there was only 1 subcomponent.

TIG

Your thinking is somewhat muddled.
A component_instance is simply a 'marker' referring to a component_definition.
A definition is a separate entities set within your SKP - it could be thought of a SKP within a SKP...
If a component_definition itself contains another sub-component_instance, then it is just that - one instance in one definition.
You can get an instance.definition and conversely a definition.instances - the second is an array of instances - if there is only one definition.instances[0] is it... However, you can't ever be sure that a definition only has one instance - there could have been several instances inserted into various different entities collections - if it is only one then it must be the instance you are interested in, but if it's actually one of a few you have almost no way of knowing which one is which... you can simply know if a definition has multiple instances from definition.instances.length>1... BUT why would you need this??

You say you want to find the 'parent' of the sub_instance - the parent is the containing definition.

If you really meant its 'definition' then that's sub_instance.definition - which you already know!

Every sub_instance you see inside duplicates of a container_component is the very same instance, i.e. if you copy the containing_instance three times each of the three containing_instance's definitions are the very same definition and then of course that contains the one sub_instance !

Unless you make a containing_instance unique [so that it then has its own definition] then when you edit the containing_instance.definition in anyway ALL instances of it will change. This applies to the sub_instance too - if you change anything in a sub_instance.definition all instances of that will change too; even if there is only one instance of it inside a containing_instance.definition all containing_instances will change to match!
IF you want to change one sub_instance inside one containing_instance then it cannot be done without affecting every other instance of either of their definitions...
To do this first you need to use containing_instance.make_unique and then refer to its NEW definition with definition=containing_instance.definition and then find the 'sub_instance' within that's definition.entities and then use sub_instance.make_unique and then edit stuff inside its sub_instance.definition... in the sure knowledge that it IS the only instance inside the only instance of a container. This is the only way you can affect the contents of one instance without affecting the contents of others that share its definition...

voljanko

Dan,your thinking makes sense,but reality is different.
I have tested the parentInstance = subComponent.parent.instances[0]
and is giving me the right instance like Aerilius writes.

The problem is that if I give an attribute (using Ruby) to one instance,it is not copied to all instances,if I assign it in dynamic components window,it is copied to all instances.So the instances are not always the same.

TIG

Dynamic components are an exception to the rule... as inserting a DC always results in it being made unique - i.e. unless you subsequently copy an instance of it within the SKP itself then every 'inserted' instance of a DC is available as dc_definition.instances[0]
A uniquified DC instance keeps it's attributes...
All dc_sub_instances are also uniquified whilst retaining their attributes...

voljanko

@tig said:

Dynamic components are an exception to the rule..

But isn't it that from the version 7 of Sketchup,every component is Dynamic?

Dan Rathbun

@voljanko said:

Dan,your thinking makes sense,but reality is different.
I have tested the parentInstance = subComponent.parent.instances[0]
and is giving me the right instance like Aerilius writes.

OK.. sorry for confusing the issue!

@TIG, thanks for clarification. (I should have waited for you weigh in on this subject, first.)

TIG

No!
Only components that are specifically made as DCs have the special dc-attributes attached to their definitions [and then also their instances] that are used to uniquify them on insertion...
To see this make a simple box component of your own [without any DC stuff], now make another type - perhaps a cylinder - and edit it, insert an instance of the first box type.
Place several instances of both types of component from the browser [or by copying]...
Now edit one instance of any one of them and you'll see that all other instances will change, including any nested instances of the box component in the cylinder component....

voljanko

The problem is not with the shape of components but with attributes.

If I assign the attribute to instance,will not copied to all instances and make the instance unique (in attribute only).
So the right assignment of the attributes should be to definitions,not to instances.And then,the instances will be all the same and happy consistent.

TIG

If you want to assign attributes to a definition then assign them to the definition [?] and they are then accessible through all instances of that definition - simply by looking at the attributes of instance.definition.
If you 'copy' a definition it will almost certainly carry the previous attributes - if you want it otherwise code it - use make_unique and then edit the new definition's attributes as needed...
Remember that component instances are individual instances pointing to the component's definition... so each one has it's own attributes - however, if the instances have been 'copied' then their attributes can be duplicated too...
Perhaps at this point it would be best it you recapped what it is you seek to do - in words rather than code-snippets... Then we might be clearer what can and can't get done... Please use words - 'parent instance of a component' doesn't actually make much sense... however with dc's you could envisage something of the sort - but phrased clearer/differently........

voljanko

My intention was to write and read some attributes to some groups and components.
After writing it to components (instances) ,it was impossible to read the attribute of the parent component(or group).
To resolve it,I have decide to write and read only to definitions of the components.
Now,before I write or read to entities, I check if the entity is group or component.
If it is a group,I read and write to this entity,if it is a component,I read and write to the definition of this component.In this way,I don't need to know the exact parent instance of the component,because all the instances have the same attributes.
So the problem is resolved