So, I have some faces in the model (root), hit G, create component, I have observer to model.entities, I do not receive any onElementAdded for the new in-place component instance resulted for making those faces a component.
I only receive onElementModified with elements and definition, but I would want to know what instance was added in place of those faces.
thanks
You would need a definitions observer to detect the new definition. You could then add an observer to the new definition to detect any instances that were added.
1 Like
I am adding a DefinitionObserver when the DefinitionsObserver onComponentAdded, the latter is called, so its all ok, but the onComponentInstanceAdded of the DefinitionObserver is not called. I wonder if its because its added inside the onComponentAdded and maybe that event already was sent and I’ve lost it.
Well that is strange, … It works fine for me (SketchUp 2016):
class MyEntitiesObserver < Sketchup::EntitiesObserver
def onElementAdded(entities, entity)
puts "onElementAdded:\n #{entity.inspect}"
end
end
# Attach the observer
Sketchup.active_model.entities.add_observer(MyEntitiesObserver.new)
I draw a rectangle, select it, hit G, enter a name and create the component being sure the “Replace selection with component” box is checked, I get:
onElementAdded:
#<Sketchup::ComponentInstance:0x0000000cad96f0>
Yes, fixed. Again, the observer system of SU strikes back.
In the onComponentAdded of DefinitionsObserver I was just definition.set_attribute for some custom stuff.
The onElementAdded of EntitiesObserver wasnt called!
Removed the set_attribute call, voila, onElementAdded is called again…
I dont understand why the developers of the API didnt thought people will modify the scene in the observers as it is normal, and usually you want to do that to create/modify/delete things based on various events.
Now I’m left with a bunch of arrays for processing on some timer, so I dont disturb the serenity of SU’s observer space 
Your call to definition.set_attribute within the DefinitionsObserver callback, is starting a new operation in the middle of another one, which breaks the call stack (apparently,) and all the subsequent queued callback calls are not made.
@tt_su ?
1 Like
Yes, as a rule, from now on I deffer operations on objects in a timer with some queues, I’ll probably generalize it for defining a set of custom operations. I have tried some observer override class I think you mentioned, but its too funky for my taste, an operation queue and a timer is more clear to me.
Perhaps you mean Thomas Thomassen’s
yes, that one. I dont remember what didnt worked, and since I’m a Ruby noob, havent tried to debug it.