there is NO **Sketchup::StylesObserver**

But the Styles class has a few 'observer-like' methods:
Styles.update_selected_style
This method is a boolean method (which should have a '?' at the end of it's name.) The use of this method is confusing (partly as the example does not show the style being selected.)
Styles.active_style_changed
(again, should have a '?' at the end of it's name.)
This is a session boolean, changes anytime after saving; but no way to trigger an event.

Would it be better to create a StylesObserver class?
That had methods such as:
--- (edit) names changed
onStyleSetAdd(styles, newStyle)
onStyleSetCreate(styles, newStyle, fromStyle)
onStyleSetChosen(styles, oldStyle, newStyle)
--- (edit) name added
onStyleSetRename(styles, style, oldName, newName)
onStyleSetRedescribe(styles, style, oldText, newText)
onStyleSetEdited(styles, style, styleOptions, optionsChangedHash)
(for Bulk handling instead of single option handling.)

Purge methods
(as in previous post (Suggested) onBeforePurge & onAfterPurge)
onBeforePurge(styles, stylesUnusedObjectArray)
onAfterPurge(styles, removedStylesArray, purgeResult)

--- (edit) the following withdrawn
onStyleEdit(styles, style, option, oldValue, newValue)*****

• probably will need to implement a "StylesOptions" OptionsProvider
  -- in favor of updates to
  RenderingOptionsObserver as in post:
  Re: StyleOptions / StyleOptionsObserver

@thomthom said:

@whaat said:

... For example, OnEntityChanged, what constitutes a 'change'?

Yea - I spent some time on this because I was setting attributes - which seems to be a change. Not sure if I want that to trigger. At least not most of the times. attributes are like meta data.
maybe onChange for geometric changes, and onAttribChange(dict, key, oldVal, newVal) for the attribute meta data?

Do changes to an Attribute currently fire onEntityChanged events?
What about adding or deleting an attribute from a Dictionary?
What about adding or deleting a Dictionary from an Entity?

@dan rathbun said:

there is NO **Sketchup::StylesObserver**

Made a few edits to proposed methods.
see original post: StylesObserver

@tig said:

• the current Render Settings are temporary changes in that View not the Scene's defined Style - if you change back to that Scene tab the Style should be refreshed back as it was until you save its changes - I know that Xray mode is perhaps a bad example in that it transcends Style settings.

My point is that what is being Rendered in a View and a Scene's Style are different things. One is transient, one is fixed.

I don't see any difference in practice.
I have 4 scenes tabs defined and have the Style dialog open in the edit pane.

Whatever I change in the Style dialog changes on the App toolbars or menus.

Whatever I change on the menus (ie Hidden Geometery,) or toolbars (shaded, xray, wireframe etc.,) is immediately echoed in the Style dialog Edit pane.

After making changes, switching between Scenes makes no changes, however I suppose all scenes are set to the same Style.

If I purposely try to set one scene to a different style, it changes, then I switch to another scene it switches back; returning to the previous scene (which I had changed does not change the Style.) It seems there is a default Model Style.

This is confusing.

@tig said:

Therefore shouldn't there be two sorts of Observer - one to watch for changes to the "Rendering Options Settings" and another to watch for "Style Changes"

Yes possibly. The API is WAY out of date on this subject and not very clear.

Likely that Rendering Options came first (before Scene Styles were 'invented'?)

@unknownuser said:

(in regard to Rendering Options) The majority of the rendering information returned exists in the Model Info > Display section of SketchUp
But that is no longer true!
There is no 'Display' section in the Model Info dialog in 7.x!

@thomthom said:

Before, Styles where called Rendering Options. So look at the RenderingOptions class. You have a RenderingOptionsObserver class: http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/renderingoptionsobserver.html

OK looked at that... seems like the RenderingOptionsObserver class needs an overhaul:

• Need to alias (rename) as: StyleOptionsObserver* Need to deprecate the old name.
  @unknownuser said:

The type is an internal number that indicates what was changed. You will need to watch the observer for numbers you are interested in.

• That is clumsy! (or lazy programming.) Ruby is a high-level language, lets have the same identifier keys as used in the RenderingOptions collection class.* RenderingOptions also needs to be aliased or renamed StyleOptions.* Need to deprecate the old name.
  This only covers the onStyleEdit method I proposed in the previous post, which is actually named onRenderingOptionsChanged, however, it fails to send any detail, it only tells (by ordinal,) what options WAS changed. I think it should pass oldValue and newValue as well.

So reproposing the method as:
onStyleOptionsEdit(styleOptionsCollection, optionKeyname, oldValue, newValue)
Could still have old method that sends ordinal number, as:
onStyleOptionsChange(styleOptionsCollection, optionNum)

• Need to deprecate the old name.

STILL, need as in previous post, a 'higher' level StylesObserver for triggering events when Styles are manipulated as a whole set (saved to, or loaded from files.) We can call these a StyleSet.

• It is possible that those methods could go in the AppObserver rather than create a new observer class.

The 'Redefine Thumbnail on Save' control checkbox is in an unnatural location (at least in my opinion.) It is currently on the 'File' page, of the 'Model Info' ToolDialog (beneath the 'Description' textarea.)

This space (on the ModelInfo dialog,) could be better used for text input controls for the Model.name and Model.tags attributes (which it seems can currently only be set thru rubyscript.)
THIS thread should discuss where the **Model.name** and **Model.tags** attribute edit controls should be located, and the use of these attributes.

It would be better (or more natural) if the 'Redefine Thumbnail(s) on Save' checkbox, was located on the 'General' page, in the 'Saving' section, of the 'Preferences' Dialog (ie: it would/should be a global setting for all models.)
To discuss where and if the 'Redefine Thumbnail on Save' control checkbox should be / or shouldn't be moved to / or IF it shouldn't be moved / and whether it should be a global setting for all models (or not.) Please go to thread: "Thumbnail Checkbox / Model.name / Model.tags"

The 'Redefine Thumbnail on Save' control checkbox is in an unnatural location (at least in my opinion.) It is currently on the 'File' page, of the 'Model Info' ToolDialog (beneath the 'Description' textarea.)

This space (on the ModelInfo dialog,) could be better used for text input controls for the Model.name and Model.tags attributes (which it seems can currently only be set thru rubyscript.)
To discuss where the **Model.name** and **Model.tags** attribute edit controls should be located, and the use of these attributes, please go to thread: "skp file format to carry keywords (tags)"

It would be better (or more natural) if the 'Redefine Thumbnail(s) on Save' checkbox, was located on the 'General' page, in the 'Saving' section, of the 'Preferences' Dialog (ie: it would/should be a global setting for all models.)

THIS thread should discuss where and if the 'Redefine Thumbnail on Save' control checkbox should be / or shouldn't be moved to / or IF it shouldn't be moved / and whether it should be a global setting for all models (or not.)

Not a 'working BUG' per se, but it's seems IMHO, a design bug.

The 'Redefine Thumbnail on Save' control checkbox is in an unnatural location (at least in my opinion.) It is currently on the 'File' page, of the 'Model Info' ToolDialog (beneath the 'Description' textarea.)

This space could be better used for text input controls for the Model.name and Model.tags attributes (which it seems can currently only be set thru rubyscript.)

It would be better (or more natural) if the 'Redefine Thumbnail(s) on Save' checkbox, was located on the 'General' page, in the 'Saving' section, of the 'Preferences' Dialog (ie: it would/should be a global setting for all models.)

OK posted two threads in Wishlist forums for discussion:

• Model.name/Model.tags:
  "Re: skp file format to carry keywords (tags)"
• Redefine Thumbnail Checkbox location
  "Thumbnail Checkbox ..."

@unknownuser said:

Why Sketchup.active_model.name returns always an empty string.

ANSWER: It doesn't ALWAYS return an empty String, it always returns the value of the name attribute (which is class String.)

But IF you never set the value of the name attribute, then of course it will 'seem' to always be an empty value, because it is.

The value can be set easily using the Model.name= method.

Example Code:

n = Sketchup.active_model.name
n.inspect
#>> ""
Sketchup.active_model.name="A newly set name for my model."
n.inspect
#>> "A newly set name for my model."

IF you are writing plugins for other users, you should not expect the name attribute to always be empty, and should (in your code,) allow for those times when the model has been assigned a name value (by the user or another plugin.)

ALSO, in the Outliner Window, the model will be listed by .title value, NOT by the .name attribute.

P.S.: I can't find a edit control, anywhere in the UI that allows setting the .name (or the .tags) attribute. They SHOULD be on the 'File' page of the Model Info ToolDialog, but are not. (This forces us to use the Console to set the name or write a lil' script to make an inputbox.)

Edited: meant to say ' .tags' attribute instead of '.note'; a note is just a Text class object, and not a attribute of the Model.

@thomthom said:

@dan rathbun said:

The Model.title method returns the basename (ie filename,) minus the file extension.

Uh? is that something SU implements? don't see it in the manual...

Woops.. sorry omitted the link. Here is is:
http://code.google.com/apis/sketchup/docs/ourdoc/model.html#title

The following simple boolean methods produce a Sketchup BUG SPLAT!, instead of returning true or false:

**$stdin.isatty STDIN.isatty STDOUT.isatty STDERR.isatty**

Platform: Win32
BUG SPLAT! reports sent

@unknownuser said:

model_name=File.basename(model_path,".skp")

was model_name=File.basename(model_path) which was including extension of a SU file.

The Model.title method returns the basename (ie filename,) minus the file extension.

Note comparison:

model_name=File.basename(model_path,".skp")
Sketchup.active_model.title == model_name
# would return true

@thomthom said:

And the anchor link http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/point3d.html#%3C doesn't work for me under FF3.5. Might be due to the < character.

I suggest the Google webmeister change the anchor to "#lessthan" instead of "#%3C".

I would suspect that links to - and + methods may have problems with some browsers as well.

@thomthom said:

In FF3.5 I don't see this behaviour. What browser do you use?

Currently still using MSIE 7

P.S.: at MSDN it indicates if the cursor is not explicitly set, the browser decides; so it may indeed be a MSIE quirk. (I have MSIE 8 and FF on the computer in another room, I'll check and see how the site looks on that machine later today.)

On the API docs pages, in the left nav column, whenever you have made a link bold, the cursor changes to a caret instead of the hand cursor. I suspect it's the <b> and </b> tags doing this.
example from the API HTML source:

<li><a href="/apis/..../model.html"><b>Model</b></a></li>

Perhaps if the bold tags were outside the anchor tags?

<li><b><a href="/apis/..../model.html">Model</a></b></li>

If the css specifically set a tags such: a {cursor:hand} the nested bold tags should inherit their parent's cursor setting (according to the css reference.)

@thomthom said:

Tools observer that let you determine what custom Ruby tool is being used.

YES I agree.
Currently all custom Tools are reported as name="RubyTool" id="50003" state=nil
(or similar.)
In my custom Tool, I've made attribute getters tool_name, tool_id, tool_state but the ToolsObserver didn't ask for them I suppose. (or maybe it's the Tools collection?)

Also the Tools collection does NOT work with custom RubyTools. Which may be the ToolObservers' problem as it gets it's info from the Tools collection.

%(#804000)[(Addition:) I'd like some VCB methods (or extra parameters passed by current methods,) to supply VCB Label and VCB value.
If new methods, something like:
onVCBlabelchange( *tools, tooldata, vcblabel* )
onVCBvalueentry( *tools, tooldata, vcbvalue* )
tooldata = Array[ tool_name, tool_id, tool_state ]

reason for labelchange event, is that we cannot rely on tool states as they vary too much, and worse, not all standard tools even use / change a tool state. So in order to know where a tool is in it's process we might be able to use what's displayed for the VCB prompt label.

It would also be nice to get the VCB value after user entry from outside of a standard tool. (I know we CAN do it within our own custom tools using the onUserText method.) Uses, well I can think of implementing a entry history for standard tools, for one.]

suggested Purgeevent methods,
fire ONCE regardless of entities removed:
(allows bulk handling in one event, instead of dealing with multiple events firing for each purged object.)

onBeforePurge(*collection, itemsObjectArray*)
onAfterPurge(*collection, itemsStringArray, purgeResult*)

(onAfterPurge must return a an array of string names because the objects are now gone; the purgeResult would be the boolean returned from .purge_unused)

for: DefinitionsObserver, LayersObserver, MaterialsObserver, StylesObserver
(and any other new observer added that gets a .purge_unused method)

(edit) **Disregard - Off Topic**
HTML

<HTML>
<HEAD>
</HEAD>
<BODY onload="GetXYfromRuby()">

<INPUT TYPE=text VALUE="" NAME="LenX">
<INPUT TYPE=text VALUE="" NAME="LenY" onchange="CalcArea()">

<!-- put this description DIV anywhere you want -->
<DIV ID="Description">This is the fabulous Rectangle component<p>You can set LenX and LenY<p>The calculated area, based on your input is <SPAN ID="Span_AreaXY"></SPAN></DIV>

<!-- at the bottom of your webDialog HTML -->
<SCRIPT Language="Javascript">
function ShowAreaXY(AreaXY) {
  Span_AreaXY.innerText=AreaXY.toString();
}
function CalcArea() {
  var AreaXY;
  AreaXY=LenX.value*LenY.value;
  ShowAreaXY(AreaXY);
}
GetXYfromRuby() {
window.location.href = 'skp;get_data@queryforXY';
// your ruby callback will do two commands;
// js_command = 'LenX.value=componentLenX;'
// js_command = 'LenY.value=componentLenY;'
// when LenY INPUT control gets value the onchange event fires
//  calling CalcArea() which then calls ShowAreaXY
}
</SCRIPT>
</BODY>
</HTML>

Havenot tested this, so you'll need to wring out the bugs.
For example of the ruby callback, See:
http://sketchupapi.blogspot.com/2008/02/sharing-data-between-sketchup-ruby-and.html

@nick60 said:

So ... Dan ... proposed solution ... not viable.

Woops.. sorry, I saw HTML and thot you were asking about webdialogs. (I guess it is the DC Properties Dialog you meant.)
... my bad!