State of Observers — 28 February 2010

State of Observers — 28 February 2010

Postby thomthom » Sun Jul 19, 2009 1:09 pm




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.
0
Last edited by thomthom on Thu Nov 19, 2009 10:17 am, edited 12 times in total.
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby Matt666 » Tue Jul 21, 2009 12:37 pm

Hi Thomthom!
Great post!
I also had some problems with entityObserver... See here. There is a problem with entities created by ruby...
0
Frenglish at its best !
My scripts

Matt666 
 

Re: State of Observers — 19 July 2009

Postby thomthom » Mon Jul 27, 2009 12:25 pm

Matt: did you find a way around your problems?
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby clarryr » Sat Aug 08, 2009 6:15 pm

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
0

clarryr 
 

Re: State of Observers — 19 July 2009

Postby AdamB » Sat Aug 08, 2009 9:54 pm

clarryr wrote: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
0
Developer of LightUp Click for website
User avatar
AdamB 
LightUp Support
LightUp Support
 

Re: State of Observers — 19 July 2009

Postby clarryr » Sun Aug 09, 2009 12:37 am

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
0

clarryr 
 

Re: State of Observers — 19 July 2009

Postby Malkomitch » Fri Aug 21, 2009 9:47 am

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
0

Malkomitch 
 

Re: State of Observers — 19 July 2009

Postby thomthom » Fri Aug 21, 2009 9:52 am

Malkomitch wrote: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.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby Malkomitch » Fri Aug 21, 2009 2:39 pm

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
0

Malkomitch 
 

Re: State of Observers — 19 July 2009

Postby thomthom » Fri Aug 21, 2009 2:52 pm

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..
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby AdamB » Sun Aug 23, 2009 7:14 pm

Malkomitch wrote: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.
0
Developer of LightUp Click for website
User avatar
AdamB 
LightUp Support
LightUp Support
 

Re: State of Observers — 19 July 2009

Postby Jim » Thu Sep 03, 2009 4:28 am

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

Jim 
Global Moderator
 

Re: State of Observers — 19 July 2009

Postby fredo6 » Sun Sep 06, 2009 11:24 pm

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)
0
User avatar
fredo6 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby thomthom » Tue Sep 08, 2009 6:23 pm

Fredo6 wrote: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)
:?:
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 July 2009

Postby Jim » Mon Sep 28, 2009 9:06 am

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.
0
Hi

Jim 
Global Moderator
 

Re: State of Observers — 28 September 2009

Postby RickW » Fri Oct 02, 2009 10:03 am

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.
0

RickW 
 

Re: State of Observers — 19 November 2009

Postby thomthom » Thu Nov 19, 2009 10:18 am

Updated to reflect finding of bugged events in SelectionObserver.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 19 November 2009

Postby thomthom » Thu Nov 19, 2009 10:32 am

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.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby thomthom » Sun Feb 28, 2010 1:52 pm

InstanceObserver.onClose does not trigger - at least not under SU7.1.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby kwalkerman » Wed May 19, 2010 6:32 pm

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
0

kwalkerman 
 

Re: State of Observers — 28 February 2010

Postby thomthom » Wed May 19, 2010 6:52 pm

kwalkerman wrote: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. :(
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

State of Observers — 3 September 2010

Postby Jernej Vidmar » Fri Sep 03, 2010 1:19 pm

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
0

Jernej Vidmar 
Modelur
 

Re: State of Observers — 28 February 2010

Postby thomthom » Fri Sep 03, 2010 2:15 pm

I've not gotten around to test the InstanceObserver - but I'll see if I can test it this weekend.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby AdamB » Fri Sep 03, 2010 6:01 pm

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.
0
Developer of LightUp Click for website
User avatar
AdamB 
LightUp Support
LightUp Support
 

Re: State of Observers — 28 February 2010

Postby spring.freediver » Wed Sep 29, 2010 9:12 pm

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?
0

spring.freediver 
 

Re: State of Observers — 28 February 2010

Postby thomthom » Wed Sep 29, 2010 9:33 pm

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?
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby thomthom » Wed Sep 29, 2010 9:36 pm

spring.freediver wrote: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)

:?:
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby thomthom » Wed Sep 29, 2010 9:37 pm

Yea - pretty sure so - because .add_observer also returns true/false . You need to keep a reference to the actual observer instance.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: State of Observers — 28 February 2010

Postby AdamB » Fri Oct 15, 2010 9:38 am

AdamB wrote: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
0
Developer of LightUp Click for website
User avatar
AdamB 
LightUp Support
LightUp Support
 

Re: State of Observers — 28 February 2010

Postby thomthom » Fri Oct 15, 2010 9:51 am

AdamB wrote: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?
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

SketchUcation One-Liner Adverts

by Ad Machine » 5 minutes ago



Ad Machine 
Robot
 

Next


 

Return to Developers' Forum

Who is online

Users browsing this forum: No registered users and 1 guest

Visit our sponsors: