State of Observers — 28 February 2010

[thomthom]

---

Out of Date!
A new list can be found here: 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+] EntitiesObserver - Could Bugsplat in earlier versions. .onContentsModified doesn't trigger.
• DefinitionObserver - Events doesn't trigger.
• InstanceObserver - Event's doesn't always trigger. Seem to be more reliable on SU6.
• MaterialsObserver - .onMaterialUndoRedo doesn't trigger. .onMaterialRemoveAll doesn't trigger correctly.
• SelectionObserver - .onSelectionAdded and .onSelectionRemoved never triggers. Instead, .onSelectionBulkChange and .onSelectionCleared always triggers.

Bugsplats!

• [SU7.0-] EntitiesObserver
• [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:

1. Attach an EntityObserver or EntitiesObserver to an appropriate entity in the model.
2. File->New to create a new model (nothing happens)
3. 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 ModelObserver.onTransactionCommit 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]

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]

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]

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]

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 unique class 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 creation of new observer class everytime it is attached to an entity, like Sketchup.active_model.entities.add_observer(MyEntitiesObserver.new)

[thomthom]

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:

Code: Select all

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

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

Code: Select all

$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]

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.

[Jernej Vidmar]

Hi guys,

seems like we have found new observer problem (MacOSX + SketchUp8). When InstanceObserver is attached to the Group and SketchUp is then exited, bugsplat window appears. If the model is saved before exiting SketchUp, no bugsplat window appears.

Code: Select all

class TestObserver <  Sketchup::InstanceObserver
   def onOpen(entity)
      p 'on called'
   end

   def onClose(entity)
      p 'onClose called'
   end
end
# Select a Skethcup Group and call this method
# so the observer will be attached to the Group
def attach_observer
   group = Sketchup.active_model.selection[0]
   group.add_observer(TestObserver.new)
end

Can anyone please confirm that?

It seems to be MAC OS X + SketchUp 8 specific problem, Windows version works OK, and SU 7 on Mac OS X too.

Cheers,
N78

[thomthom]

I've not gotten around to test the InstanceObserver - but I'll see if I can test it this weekend.

[AdamB]

Yes, I can confirm its a repeatable bug on Mac OSX SketchUp 8.

I've logged a very grumpy bug report with Google.

Useful to know you can stop the crash by saving before exiting, but I am disappointed a bug like this could be missed. I know software has bugs in it etc, but this seems like any basic regression testing / smoke testing would flush this one out.

[spring.freediver]

Does the View.remove_observer method work in SU7.1?

I have a tool that needs to turn a ViewObserver on and off.

In tool methods that receive a view argument:
I use "@observer = view.add_observer(MyViewObserver.new)" to turn it on;
and "view.remove_observer(@observer)" to turn it off.

view.remove_observer returns false, and the observer is not removed.

I tried changing @observer to a class variable (@@observer), and it still did not work.

Any ideas?

[thomthom]

hm... I have not tried to remove observers from view objects...

btw - I am compiling a new observer list: viewtopic.php?f=180&t=30793
If you find new information not included in the list - can you please let me know so I can update the list?

[thomthom]

Does the View.remove_observer method work in SU7.1?

I have a tool that needs to turn a ViewObserver on and off.

In tool methods that receive a view argument:
I use "@observer = view.add_observer(MyViewObserver.new)" to turn it on;
and "view.remove_observer(@observer)" to turn it off.

view.remove_observer returns false, and the observer is not removed.

I tried changing @observer to a class variable (@@observer), and it still did not work.

Any ideas?

Hang on... aren't you suppose to do it like this:
@observer = MyViewObserver.new
view.add_observer(@observer)
...
view.remove_observer(@observer)

[thomthom]

Yea - pretty sure so - because .add_observer also returns true/false . You need to keep a reference to the actual observer instance.

[AdamB]

Yes, I can confirm its a repeatable bug on Mac OSX SketchUp 8.

I've logged a very grumpy bug report with Google.

Useful to know you can stop the crash by saving before exiting, but I am disappointed a bug like this could be missed. I know software has bugs in it etc, but this seems like any basic regression testing / smoke testing would flush this one out.

After I'm done with a Tool, I always done .pop_tool rather than .select_tool(nil) because it seems less presumptuous. ie restore what the user was doing before rather than cancel their previous selection.

However, Gaieus found out a problem/conflict with Jim Toolbar Organizer - long story short, I've switched to doing select_tool(nil) to avoid some weird race-condition with menu validation procs.

But it seems to have cured the crash on exit of SU8 on Mac when using Observers as well...

Adam

[thomthom]

After I'm done with a Tool, I always done .pop_tool rather than .select_tool(nil) because it seems less presumptuous. ie restore what the user was doing before rather than cancel their previous selection.

However, Gaieus found out a problem/conflict with Jim Toolbar Organizer - long story short, I've switched to doing select_tool(nil) to avoid some weird race-condition with menu validation procs.

But it seems to have cured the crash on exit of SU8 on Mac when using Observers as well...

what? damn! I rely on this feature for a plugin I'm making. what kind of race condition? you got a small example?
windows, osx?