State of Observers — 28 February 2010

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

[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 usingselect_tool, or by calling "evian()" which starts it using push_tool.

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

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?

[Dan Rathbun]

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.

This issue is caused by the tool stack having no tool_id (or more precisely Tools.active_tool_id == 0 ).

NOTE: Calling active_tool_name on an empty Tools collection might cause a crash. Before calling this method, it is important to check whether or not the Tools collection is empty. The Tools collection is empty if the method .active_tool_id returns zero.

So always check if tools.active_tool_id==0 before using .pop_tool() or .active_tool_name()

[Dan Rathbun]

---

onQuit() callback

---

I have noticed that on SU 8.0M1 (at least,) that Sketchup does not wait until the callback returns, before it closes all it's child and owned popups, and it's own app window and shuts down.

You can still have code in an onQuit() callback running after all Sketchup's windows have closed. (You can try it with a messagebox.)

I was trying to save size and position of some windows, but Sketchup closes all it's windows before my onQuit() callback code can use Win32API calls to grab the window sizes. I even 'leaned' the code out as much as possible, but still to no avail, ... my code writes empty size arrays into the registry.

My next choice will be to try and use Ruby's built-in define_finalizer for one of my objects, perhaps the plugin module, or the observer object, .. and see if Sketchup will wait until the finalizer block returns.

Did anyone notice this behaviour in SU 7.x ?

[Dan Rathbun]

Quick Question ...

Seems I remember that AppObserver::onNewModel does not get called when Sketchup starts up.

Is this generally true.. or specific to PC or Mac ?

I see the API says that a command line skp file will not fire the onOpenModel() callback.

[thomthom]

Seems I remember that AppObserver::onNewModel does not get called when Sketchup starts up.

Is this generally true.. or specific to PC or Mac ?

Aye.