Sketchup.find_support_file

tomasz

Driven has suggested in this thread that Sketchup.get_resource_path("") gives constant results.
It returns the resources path though.

tomasz

@unknownuser said:

Sketchup.find_support_file("", "Plugins/")
nil

Sketchup.find_support_file("", "")
nil

Sketchup.find_support_file("")
nil

Sketchup.find_support_file "plugins"
/Library/Application Support/Google SketchUp 6/SketchUp/plugins

It is a report from SU6 user on MAC.

Dan Rathbun

(1) Only use double-quoted Strings if your:

using Regular Expressions (ie: "\n")* doing #{strVar} replacement
(2) You'll have fewer problems with the interpreter if you get in the habit of putting ( ) around parameters whenever possible, and with NO space between the method name and the (.

To find the Sketchup folder(directory) try:
File.dirname(Sketchup.find_support_file('sketchup.exe'))

Plugins folder, is empty when SU is first installed, so can't test for a file, but, you can append 'plugins' to the above, using File.join which uses File::SEPARATOR between arguments:
File.join(File.dirname(Sketchup.find_support_file('sketchup.exe')),'plugins')

Note: Sketchup.find_support_files (plural) on PC returns escaped backslash pathnames, and sometimes returns arrays of pathnames. It's a pain in the butt.

Jim

Mac use .exe?

How about using $LOAD_PATH[0]? Is it reliable?

Dan Rathbun

@jim said:

Mac use .exe?

Well.. the point I need to make is.. That Sketchup.find_support_file works best if it has a file to find. In the old days we could not give directories names with .extensions, so we could find dirs with '*.' wildcard. That's not true anymore with 32-bit filesystems.
He can put a string reference into the method call, and set the reference using a platform conditional statement; sketchup.exe for PC, and whatever it is for Mac.

@jim said:

How about using $LOAD_PATH[0]? Is it reliable?

Not if the user has moved their paths around.

However.. hmmm... you could always iterate the $LOAD_PATH array, check each element if it includes 'plugins'
` target=''
$LOAD_PATH.each {|e| target=e.dup if e.downcase.include?('plugins')}
if (not target.empty?) and File.basename(target).downcase=='plugins'

Plugins target path is good!

end`

EDIT: put ( ) around not target.empty? just in case...

tomasz

@dan rathbun said:

You'll have fewer problems with the interpreter if you get in the habit of putting ( ) around parameters whenever possible, and with NO space between the method name and the (.

I do have () without spaces in most cases

@dan rathbun said:

` target=''
$LOAD_PATH.each {|e| target=e.dup if e.downcase.include?('plugins')}
if (not target.empty?) and File.basename(target).downcase=='plugins'

Plugins target path is good!

end`

It looks like a good solution.

MartinRinehart

@dan rathbun said:

$LOAD_PATH.each {|e| target= ...

May I cast one vote for the for ... in ... loop? I adopted it for my tutorial as I was writing for programmers and programming newbies. Then I read that it was indeed faster. And as a long-time, big-time fan of readable code, whatever.each {|x| ... wins no prizes.

for path in $LOAD_PATH do ... end

MartinRinehart

@unknownuser said:

Hi all,
I have reports from users that Sketchup.find_support_file "plugins" returns nil although the folder exists

On a PC (where it doesn't matter) the folder is "Plugins". Is the issue simply capitalization?

I direct users to find their Plugins folder via Sketchup.find_support_file "Plugins" in the Ruby Console. Zero problems reported.

Jim

A for-loop is not a drop-in replacement for .each.

Variables created in a for loop which you might assume have loop scope are actually visible outside the loop when the loop terminates.

Variable created in the .each loop behave as local to the loop, as expected.

At least on Ruby version 1.8. I don't know what Matz decided the behavior will be on Ruby 1.9.

MartinRinehart

@jim said:

Variables created in a for loop which you might assume have loop scope are actually visible outside the loop when the loop terminates.

Thanks!

Ruby never ceases to amaze me.

Dan Rathbun

Actually Martin.. that example was quick and dirty.

It CAN be cleaned up. I was thinking it would be better to break out of the iteration when the proper match was found, rather then keep iterating, though how many paths do most people have in their $: anyway?

You'd likely run a method and set a constant (perhaps Integer index into $LOAD_PATH) and then use that reference from then onward. So it should be a one time, startup type thangy...

One thing I do is actually put set ENV['SUpath']