State of Observers — 28 February 2010

Matt666

Hi Thomthom!
Great post!
I also had some problems with entityObserver... See here. There is a problem with entities created by ruby...

thomthom

Matt: did you find a way around your problems?

clarryr

I am also looking at the reliability of the observer classes. So far I've found that the model passed to ModelObserver.onDeleteModel is wrong. When the model started I set model.name = "myname". On all the other methods I tested in ModelObserver I was able to see myname. Not so on onDeleteModel.
Larry

AdamB

@clarryr said:

I am also looking at the reliability of the observer classes. So far I've found that the model passed to ModelObserver.onDeleteModel is wrong. When the model started I set model.name = "myname". On all the other methods I tested in ModelObserver I was able to see myname. Not so on onDeleteModel.
Larry

Yep. My understanding is that all delete methods are called after the fact. So the referenced object is toast by the time you are invoked.

Furthermore, I believe most problems caused by Observers is hanging onto stale references to Ruby objects that have been deleted. If you create null (do nothing) Observers, they are benign.

Adam

clarryr

@unknownuser said:

Yep. My understanding is that all delete methods are called after the fact. So the referenced object is toast by the time you are invoked.

Furthermore, I believe most problems caused by Observers is hanging onto stale references to Ruby objects that have been deleted. If you create null (do nothing) Observers, they are benign.

Adam

That's pretty much what I guessed. Unfortunately, the model reference passed in is not nil. It doesn't seem to reference anything but it doesn't compare equal to nil and it's not the active_model either. Ruby seems to be pretty good about detecting and reporting method calls on nil but I can see where having this mystery model reference might cause problems. Bottom line seems to be to clean up in onSaveModel and ignore onDeleteModel. I was trying to be a good citizen and remove all of my observers when the model was deleted but Sketchup doesn't seem to care or has already removed them.
One thing I can do when onDeleteModel is called is I do know 'self', so if I need to I can track all of my other observers as instance variables of my model observer.
Larry

Malkomitch

EntitiesObserver works well if you don't erase any entity inside the observer.
Otherwise, it makes Sketchup crash in an ugly way.

I'm not sure about EntityObserver but i think that's pretty much the same behavior.

Thank you for the report

thomthom

@malkomitch said:

EntitiesObserver works well if you don't erase any entity inside the observer.
Otherwise, it makes Sketchup crash in an ugly way.

I'm not sure about EntityObserver but i think that's pretty much the same behavior.

Thank you for the report

In my experience I found adding the observers to cause a delayed crash no matter what - even if I never modified the model. Just attaching it.

Malkomitch

Do you call the same observer several times?

for example, if an AppObserver.onNewModel of your own call a new EntityObserver each time you perform a File>New, you'll stack the EntityObservers without removing the old one. Every methods trigger n times and it may cause unwanted issues.

try to track your observers by storing them in a global variable, for example. And if you find some duplicates, use Sketchup.active_model.entities.remove_observer before calling a new one

In my scripts, if i use observers, i'm used to call a little function "refreshObservers" of my own, triggered by AppObserver.onNewModel or AppObserver.onOpenModel, that flushes all the old observers and create new ones.

I'm using an EntitiesObserver every day. This observer is designed to build and update a catalogue of everything drawn in or removed from sketchup. With onElementAdded and onElementRemoved, I never experienced any crash, excepted when I try to remove an entity inside the EntitiesObserver methods. It breaks the elementary rule: don't touch the collection you're watching in

thomthom

hmm... will have to look deeper into it again. but I mean to remember that even when I removed the observers I still got crashes... hm..

AdamB

@malkomitch said:

try to track your observers by storing them in a global variable, for example. And if you find some duplicates, use Sketchup.active_model.entities.remove_observer before calling a new one

Very good advice. Also remove_observer will accept without error an observer that is currently not attached - I always use the cliche of "remove followed by add" to ensure you have just 1 observer.

Jim

I just noticed the AppObserver onNewModel event fires even if you hit the Cancel button on the "Save changes" dialog.

fredo6

Maybe the most efficient is to use a uniqueclass instance for ALL observers.
The observer class does not even need to be typed (i.e. a subclass of the Sketchup observer classes), as there is no check done by the methods add_observer (like for the Tool classes).

All callback methods have different names and the relevant information is always in the arguments, so that you have the context of the entities and objects you 'observe'.

This unique instance can easily be maintained at module level.

Fredo

PS: it is a little bit misleading that the API documentation always shows examples with creationof new observer class everytime it is attached to an entity, like Sketchup.active_model.entities.add_observer(MyEntitiesObserver.new)

thomthom

@unknownuser said:

PS: it is a little bit misleading that the API documentation always shows examples with creation of new observer class everytime it is attached to an entity, like Sketchup.active_model.entities.add_observer(MyEntitiesObserver.new)

Jim

I don't know if this is "right" or not, but here is my approach.

I created a global $jf_observers = {}
Then, create a single instance of the observers I need:

$jf_observers[;layers] = JF;;LayersObserver.new

When I need an observer, I register a block of code:

$jf_observers[;layers].register(;onLayerAdded) { |layers, layer| do_something(layer) }

At this point, the observer is attached if it isn't attached (an AppObserver is also created and attached because it needs to re-attach any other observers onNewModel and onOpenModel.)

But, there is only a single instance of each observer in existence. There are a handful of entity-specific observers that do not fall under the AppObserver control. But all of the model-level observers can.

Using this method, any developer can use an observer simply by registering a block of code to be executed on an event. .register returns an id so you can later .unregister(id) the event, too. The observers detach themselves when there are no more events in their queues. I don't really ever see a reason to detach the AppObserver - it can stay attach forever.

I am in the process of coding a "suit" of observers that behave in a similar fashion, but I am not really far enough to know if it is a viable or stable strategy; although I think it is a solid approach.

RickW

For my part, I created the SmustardAppObserver that allows plugins to add calls to the Observer instance. When an event is triggered, the observer will parse the list of calls.

thomthom

Updated to reflect finding of bugged events in SelectionObserver.

thomthom

There also seems to be some oddness with DefinitionsObserver. Event's unexpectedly triggering. At least in SU7.1.

SU6:

Group/Component Creation: onComponentPropertiesChanged
Paste: onComponentPropertiesChanged

SU7:

Group/Component Creation: onComponentPropertiesChanged
Paste:
Before you place the component: onComponentRemoved and onComponentPropertiesChanged
After: onComponentRemoved
Ctrl+Move: onComponentRemoved

Not sure if the onComponentRemoved started triggering in SU7.0 or 7.1.

thomthom

InstanceObserver.onClose does not trigger - at least not under SU7.1.

kwalkerman

EntityObserver - (and possibly others)

it seems that OnEraseEntity is activated after onChangeEntity, which means that if the entity is erased, it can cause bugs for whatever you are trying to do with OnChangeEntity. If OnEraseEntity were activated first, you could create a simple boolean value:

def initialize
@still_here = true
end

def OnEraseEntity(entity)

whatever you want to do...

@still_here = false
end

def OnChangeEntity(entity)
if (still_here)

whatever you want to do...

end
end

This is a problem because the entity seems to be erased before OnChangeEntity is called, which means that doing something to the entity gives errors, but your observer doesn't know it until it gets through OnChangeEntity to OnEraseEntity.

--
Karen

thomthom

@kwalkerman said:

This is a problem because the entity seems to be erased before OnChangeEntity is called, which means that doing something to the entity gives errors, but your observer doesn't know it until it gets through OnChangeEntity to OnEraseEntity.

Yea - the Entity and Entities observers aren't easy to deal with.