Template loaded programmatically doesn't use style

thatClintGuy

Hello sketchUcation!

I've been cutting my Ruby-teeth updating my company's extension to work in 2014. This forum has been a great resource so far. When I get into the thick, I tend to have a bunch of tabs filled with the SketchUp Ruby API and sketchUcation threads. So thanks!

Now onto my question:

Having a helluva time getting a style to load when my extension is on. I've created and saved a template with the style I want in the SketchUp UI that works perfectly when I create a new file.

However, if I copy that .skp file from the Templates directory and set the template in Ruby, the styles don't work.

I'm setting the template in an AppObserver using the following code:

Sketchup.template=Sketchup.find_support_file("Plugins")+"/MyPluginDir/template.skp"

When I call Sketchup.template it happily reports the correct path to the file.

Have been wondering if styles aren't embedded in .skp files, but point to a style file/setting already in SketchUp, which wouldn't exist on an end-user's setup.

Am I missing something?

Dan Rathbun

Yes there are style files (.style) and an API Sketchup::Style class for them, and each model has it's own Sketchup::Styles collection class to hold them (so you may need to load a style into a model's styles collection.)

The locations for templates and styles have NOT YET been updated to the AppData paths like the plugins and classifications.
They both are still in the binary path (on Windows at least.)

This presents some issues.

Trying to point somewhere else is problematic I think. Presently SketchUp does not handle having multiple template directories.
For now templates are in a langauge localized sub-directory of the "Resources" directory, in the binary path. It might be better to copy your template file there (if you can workaround folder permission issues.)
Sketchup.get_resource_path "Templates"
But if you can get it to work by pointing Sketchup's template directory to your plugin path, then ok, as long as the user can reverse this. They may wish to do normal modeling without your plugin "hijacking" the template.

Styles directory can use multiple path for the styles browser dialog.
The Styles path in the registry seems to be set to the user's Documents path at install.
But this path cannot be read (on PC,) using:
Sketchup.read_default("File Locations","Styles")
The applications styles root directory can be returned using:
Sketchup.find_support_file "Styles"

.

thatClintGuy

So if I understand correctly, the style information in a .skp is just a pointer to a .style file that needs to exist on the client machine?

This is getting trickier for just changing the background color.

It worked fine in 2013 to just load a template, but maybe something changed.

thatClintGuy

Discovered the easy solution to changing the background color to black. One line of code:

Sketchup.active_model.rendering_options["BackgroundColor"] = Sketchup::Color.new(0,0,0)

Dan Rathbun

@thatclintguy said:

So if I understand correctly, the style information in a .skp is just a pointer to a .style file that needs to exist on the client machine?

I did not mean to have you think this. You asked if there was file based styling.
And I pointed out that there is, and gave you class names, expecting you to read up on them in the API Dictionary.
But that documentation leaves much to be desired !
Errors, Vagueness, etc.

So, again, styles can be imported into the model's Styles collection, and of those that are loaded, one of the Style instance objects can be set as active.

You can also save out your "company" styling as a .style file, that can be imported into any skp (be it template or working model file.)

@thatclintguy said:

This is getting trickier for just changing the background color.

When a style is activated, it's properties are loaded into the model's instance of the RenderingOptions collection class.

Notice the "BackgroundColor" key ?

Also, be aware that each scene page can (but does not have to,) save it's own RenderingOptions hash. A property flag must be set to do so.
IF the flag is set, it can override the model level rendering options.

@thatclintguy said:

It worked fine in 2013 to just load a template, but maybe something changed.

Find out if anything changed.
Any different plugins ?

Be sure that when you edit the template, before you save it:
(1) Check that you have loaded the style file (if using a file based style,) and set as the active style.
(2) Look in the Style Manager. Click on the "In Model" button, and see if more than 1 style is in the model's styles collection. (This may be likely if you started with an supplied template.)
If so, activate your style before saving the template.

?

Dan Rathbun

OK. Wait. I just re-read what you wrote in the OP.

It seems that you believed that Sketchup.template=() would load a template (dynamically) into the currently loaded model.
It should not. It only should set up subsequent calls to open a NEW model, to use the specified template.
Sketchup.send_action("newDocument:")
or
Sketchup.file_new()

To load a style dynamically, load a .style file into the styles collection, and set it active by name or index.

Dan Rathbun

I DID find a change, but it is "under the hood".

The "Preferences" attribute name (for the template path) changed:

"DefaultTemplate"
SU2013 and earlier: Shared by the Ruby Sketchup.template=() and the "Browse" button in the Preferences dialog (Template panel.)
SU2014: Ruby Sketchup.template=() method.

"DefaultTemplate14"
SU2014: "Browse" button in the Preferences dialog (Template panel.)

thatClintGuy

@dan rathbun said:

OK. Wait. I just re-read what you wrote in the OP.

It seems that you believed that Sketchup.template=() would load a template (dynamically) into the currently loaded model.
It should not. It only should set up subsequent calls to open a NEW model, to use the specified template.
Sketchup.send_action("newDocument:")
or
Sketchup.file_new()

To load a style dynamically, load a .style file into the styles collection, and set it active by name or index.

Good catch, but I didn't believe that, actually. I was calling file_new after setting the new template, but the template style background still wasn't being used when it was outside the default templates directory for some reason.