State of Observers — 28 February 2010

thomthom

%(#BF0000)[Out of Date!
A new list can be found here: http://forums.sketchucation.com/viewtopic.php?f=180&t=30793&p=270781#p270781]

Update — 28 September 2009
As of SU7.1 it appears that some observers behave better. Trying to get confirmation on this.

Update — 2 October 2009
Many of the MaterialObserver events seems to be working after all. At least in SU7.1. Will have to check with older versions again.

Update — 19 November 2009
Two events of the SelectionObserver doesn't trigger. Seems to go back to at least SU6.

Update — 28 February 2010
InstanceObserver.onClose does not trigger - at least not under SU7.1.

When I started my work on my DoubleCut plugin I ended up dealing allot with Sketchup's Observers. As it turns out, it's a treacherous land. Some simply doesn't work and some are bugged. Some are so bugged they crash Sketchup.

The information about the gotchas was scattered and few, so I've compiled my own list here: (SU6 + SU7)

Works

AppObserver
DefinitionsObserver
[SU7.1+] EntityObserver - Could Bugsplat in earlier versions.
LayersObserver - ( .onCurrentLayerChanged also triggers if you rename the current layer.)
ModelObserver
ToolsObserver - (Might be some weird behaviour with this one. Not been able to confirm.)
OptionsProviderObserver
PagesObserver
RenderingOptionsObserver
ShadowInfoObserver
ViewObserver

Bugged

[SU7.1+] [ruby:pdy3it1z]EntitiesObserver[/ruby:pdy3it1z] - Could Bugsplat in earlier versions. [ruby:pdy3it1z].onContentsModified[/ruby:pdy3it1z] doesn't trigger.
[ruby:pdy3it1z]DefinitionObserver[/ruby:pdy3it1z] - Events doesn't trigger.
[ruby:pdy3it1z]InstanceObserver[/ruby:pdy3it1z] - Event's doesn't always trigger. Seem to be more reliable on SU6.
[ruby:pdy3it1z]MaterialsObserver[/ruby:pdy3it1z] - [ruby:pdy3it1z].onMaterialUndoRedo[/ruby:pdy3it1z] doesn't trigger. [ruby:pdy3it1z].onMaterialRemoveAll[/ruby:pdy3it1z] doesn't trigger correctly.
SelectionObserver - [ruby:pdy3it1z].onSelectionAdded[/ruby:pdy3it1z] and [ruby:pdy3it1z].onSelectionRemoved[/ruby:pdy3it1z] never triggers. Instead, [ruby:pdy3it1z].onSelectionBulkChange[/ruby:pdy3it1z] and [ruby:pdy3it1z].onSelectionCleared[/ruby:pdy3it1z] always triggers.

Bugsplats!

[SU7.0-] [ruby:pdy3it1z]EntitiesObserver[/ruby:pdy3it1z]
[SU7.0-] EntityObserver
(Seems to be fixed in SU7.1)
They cause strange bugsplats when using. I've seen this behaviour on both SU6 and SU7, both with clean installations. These observers doesn't crash SU immediately, but sneaks up on you later on. The only simple semi-reliable way to recreate the bug I know is this:

Attach an EntityObserver or [ruby:pdy3it1z]EntitiesObserver[/ruby:pdy3it1z] to an appropriate entity in the model.
File->New to create a new model (nothing happens)
File->New again to create a new model - bugplat
This doesn't happen every time. Some times you need to do some more File->New - maybe draw some geometry. But once either one of these observers are used SU will at some point crash with a bugsplat.
I have tried to remove the observers after creating them, but that doesn't seem to help at all. Once one of them has been used SU becomes volatile.

Other notes
Another thing I learned was that doing modifications to the model on observer events can cause lots of problems.

If a script is doing something which trigger an event that modifies the model it will break the undo stack. I also seem that it can make SU unstable. You could potentially cause infinite loops.
After consulting with Scott it seems that queueing up a list of modifications to be done to the model and executing the list on [ruby:pdy3it1z]ModelObserver.onTransactionCommit[/ruby:pdy3it1z] is the most reliable way to do it.

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