State of Observers — 28 February 2010

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

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.

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: http://forums.sketchucation.com/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

@spring.freediver said:

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

@adamb said:

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

@adamb said:

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?