OnActiveModelObserver
-
I have already filed formal Feature Requests for onModelFocus and onModelBlur (and onReadyState) callbacks for the
Sketchup::AppObserverAnd.. top on my list.. is the fix for
onQuit -
Thanks thomthom and Dan. I was afraid of that. Oh well, I am sure I can find a work around.
-
Also I filed a Feature Request for a
Sketchup::Modelscollection (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 returnstrue, 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 returningnil.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. -
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.
-
@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 said:
I have already filed formal Feature Requests for onModelFocus and onModelBlur (and onReadyState) callbacks for the
Sketchup::AppObserverActually I filed Feature Requests for onFocus and onBlur callbacks for the
Sketchup::ModelObserver..and:
onReadyState callback for the
Sketchup::AppObserverI 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.
-
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.
-
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.
-
@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.
-
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#modelOr from the Selection itself?
https://developers.google.com/sketchup/docs/ourdoc/selection#modelThere are a number of objects which can give you their model:
model : Entities
model : Entity
model : Selection
model : Tools
model : View -
@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#modelOr from the Selection itself?
https://developers.google.com/sketchup/docs/ourdoc/selection#modelHmmmmm! 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.
-
@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.
Advertisement