OnActiveModelObserver

Chiefwoodworker

I was going to add this comment to the Observer's WishList but I am not sure I really have a problem or know what I am talking about. So I will pose it as a question.

I have a script that opens a WebDialog. The script works fine on the PC. However, the Mac allows multiple models to be open with only one having focus and the one with focus is the active model. When the active model changes I need to switch and update the WebDialog.

Is there an observer for "onActiveModelChange" that would trigger when the Mac (or PC for that matter) changed active models? If there is a way to currently do this could someone tell me how. If not, I would like to see this high on the Observer's WishList. By the way, onNewModel and onOpenModel do not work for this application because I need an observer that triggers when switching between already open models on the Mac.

thomthom

I'm afraid you've run into one of the limitations of the SketchUp observer events. There currently is none.

Dan Rathbun

I have already filed formal Feature Requests for onModelFocus and onModelBlur (and onReadyState) callbacks for the Sketchup::AppObserver

And.. top on my list.. is the fix for onQuit

Chiefwoodworker

Thanks thomthom and Dan. I was afraid of that. Oh well, I am sure I can find a work around.

Dan Rathbun

Also I filed a Feature Request for a Sketchup::Models collection (which would always have only one member on the PC,) so we could track multiple open models on the Mac's MDI interface.

I had attempted (and I think both ThomThom and Driven have also,) to write my own edition of it, using a Hash, Array or Set. But there are bugs in the API that make it problematic. I kind of gave up on it.

For example... on the PC, you grab a handle to the current model. You then open another which closes the previous one. You grab a handle on the new model. Then you test the handle for the old one, using model.valid? and it returns true, even though that model is closed.
Even weirder... if you use the old handle to access other collections, such as selection, materials etc., the methods return handles to the new model's collection objects, instead of returning nil.

I think another issue is that from time to time, perhaps saving the model out to a file, etc., the API silently generates a new Ruby object (with a new object_id,) for the active model. We have reported these things. That and several other methods that return singleton objects, collections or interfaces, return a different object_id each time they are called, and should not do this. For instance... the handle to the "Window" menu, should be the same, for all scripts, throughout a given session.

Chiefwoodworker

One wonders if, and hopes, these things will get resolved more quickly under the Trimble umbrella. I am trying to come up with a work around and have fallen into similar problems to those you describe Dan. Thanks for the summary.

Dan Rathbun

@chiefwoodworker said:

One wonders if, and hopes, these things will get resolved more quickly under the Trimble umbrella.

I certainly am hoping for this !!
Running out of patience. I have a growing set of plugins, that I cannot finish without certain API bug fixes and obvious missing interfaces, classes and methods.

@unknownuser said:

I am trying to come up with a work around and have fallen into similar problems to those you describe Dan. Thanks for the summary.

Other threads on this subject:

There was a thread, in which, ThomThom, driven, and I, discussed possible workarounds. But I cannot find it now. In it, John (driven,) said something like, he tracks the object_id of one of the collections (materials or definitions,) as he thought it's object_id was stable, even if the active model's id changed.

[Question] multi document interface and Tools

Here's a classic example of how this issue affects plugin tool development. If you read the post you'll see how I ran into problems with the the Mac MDI, with class variables. (These were changed from global vars to class vars by ME, from the original example in the book.) Worked great on PC, but failed on the Mac, if the user switched to another model, and attempted to use the same tool.
[ Code ] Scarpino's SphereTool Sample ver 2.1.0

Dan Rathbun

@dan rathbun said:

I have already filed formal Feature Requests for onModelFocus and onModelBlur (and onReadyState) callbacks for the Sketchup::AppObserver

Actually I filed Feature Requests for onFocus and onBlur callbacks for the Sketchup::ModelObserver

..and:

onReadyState callback for the Sketchup::AppObserver

I also requested some onClose type of callbacks, for whichever of the two they should be put in.

Sheesh.. I've filed so many requests, I cannot remember them all, anymore.

Chiefwoodworker

I came up with a work around using the timer to monitor changes in Sketchup.active_model. A kind of home brew observer. When a change in Sketchup.active_model is noticed I update necessary variables with Sketchup.active_model.selection and other state. This allows me to use the same WebDialog independent of the SketchUp model currently active. Works great on both the Mac and PC. Thanks for the help.

Jim

Hi Joe,

If this is only for WebDialogs, it may work to update the variables when the dialog receives focus, i.e use the window.onfocus event to trigger a callback that updates the model and variables.

Alternatively, if you are using a generalized method to perform the callback to the Ruby plugin, then your callback dispatcher could do the update before calling the callback method.

Chiefwoodworker

@jim said:

Hi Joe,

If this is only for WebDialogs, it may work to update the variables when the dialog receives focus, i.e use the window.onfocus event to trigger a callback that updates the model and variables.

Alternatively, if you are using a generalized method to perform the callback to the Ruby plugin, then your callback dispatcher could do the update before calling the callback method.

Hi Jim,

Unfortunately window.onfocus trigger doesn't work in this application. My WebDialog is sort of an extended Entity Info dialog box (it is actually called Extended Entity Info). The user can inspect components by just clicking on them one after the other. As he/she does this the Extended Entity Info dialog box needs to update with the new Sketchup.active_model.selection. So in this situation it never receives focus, but is expected to update anyway.

In addition, when the active model is changed, e.g. by switching between multiple open models on a Mac or opening a new model on the PC, the same WebDialog needs to update with the new Sketchup.active_model.selection on the new active model without ever receiving focus.

Jim

Good idea for a plugin.

Is this a Tool class, or are you using a SelectionObserver?

Either way, can't you just get the active model from the selected entity?
https://developers.google.com/sketchup/docs/ourdoc/entity#model

Or from the Selection itself?
https://developers.google.com/sketchup/docs/ourdoc/selection#model

There are a number of objects which can give you their model:

model : Entities
model : Entity
model : Selection
model : Tools
model : View

Chiefwoodworker

@jim said:

Good idea for a plugin.

Is this a Tool class, or are you using a SelectionObserver?

Sort of and Yes. It is not a drawing tool, but the tool adds attributes to a component(s) using dictionaries. I use selection observers to let the tool know when a selection has changed (by the way, selection observers don't play well with the Outliner and I have already filed a bug report on that).

@jim said:

Either way, can't you just get the active model from the selected entity?
https://developers.google.com/sketchup/docs/ourdoc/entity#model

Or from the Selection itself?
https://developers.google.com/sketchup/docs/ourdoc/selection#model

Hmmmmm! Now you have me thinking. The only problem I can see with that approach is that the Extended Entity Info box would get updated when a new selection is made after a new model became active. The time between a new active model and a new selection could be relatively long and during that period the incorrect, and potentially misleading data, would remain in the Extended Entity Info dialog box. That may not be a huge problem though.

I have to give that approach some more thought. My timer work around is working well at the moment and I am inclined to leave it alone (though I do prefer real observers versus periodic sampling observers).

By the way, this tool is described in it's User's Manual at http://www.srww.com/downloads/CutList%20Bridge/CutList%20Bridge%20User%27s%20Guide.pdf if you are interested. I also wrote about it in my June newsletter at http://www.srww.com/blog/wp-content/uploads/Chiefwoodworker%27s%20Newsletter/Chiefwoodworker%27s%20Newsletter%206-11-2012.pdf.

Dan Rathbun

@jim said:

Either way, can't you just get the active model from the selected entity..
Or from the Selection itself?

Keeping in mind that on Mac there can be multiple model objects open.. each with it's OWN selection object, which it's it's OWN selected entity.