State of Observers — 28 February 2010

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?

AdamB

Ok, it appears to be that if you select_tool but then pop_tool, things can get fubar.

Mostly its benign - hence I got away with it - but with the LargeToolSet showing from Jim's Tool Organizer, the additional calls to the validation procs reveal the error. In that it is wrong to be selecting a tool then popping it, but you might hope SU would just ignore it.

The attached Ruby is a simple Tool that always performs pop_tool on keypress Escape.

It can be invoked either by calling "baddoit()" which starts it using select_tool, or by calling "evian()" which starts it using push_tool.

poptool.rb

thomthom

Ok, so:

select_tool + pop_tool = fubar
but
push_tool + pop_tool = OK

Thought I'd tried pop_tool with select_tool before - without pop_tool doing anything. Thought it only worked after push_tool.

AdamB

@thomthom said:

Ok, so:

select_tool + pop_tool = fubar
but
push_tool + pop_tool = OK

Thought I'd tried pop_tool with select_tool before - without pop_tool doing anything. Thought it only worked after push_tool.

Not quite. select_tool + pop_tool = fubar isn't always terminal. Just apparently if there are really large toolbars around hence its never caused a problem for me in the past.

Thomthom, can you get Jims' Organiser thing and see if you can repro this.

thomthom

Size of toolbars matter?
Or is it toolbars with validation procs?

I have Jim's plugin installed on my Sy7 installation. Is it a particular pre-set toolbar that should be tested against?