Open SU vs open model - __FILE__ might vary

Chris Fullmer

Not of great consequence probably, but I came across an oddity on my Win XP machine. The __FILE__ reference returns a different string when SketchUp is opened by clicking on the actual SketchUp icon vs clicking on a model file. It cause me a little grief in a quick hardcoded string comparison I was playing with.

Clicking on the sketchup icon, __FILE__ gives me:
C:/Program Files/Google/Google SketchUp 8/Plugins/multiflux_loader.rb

Clicking on the model file __FILE__ gives me:
C:/PROGRA~1/Google/GOOGLE~3/Plugins/multiflux_loader.rb

Clearly the same path per se. But the string is not comparable. So don't rely on simple path string comparison on loading without being aware that the sting will not always be the same.

TIG

This is the old 'DOS-path' way versus the 'sensible-path' way!
Both of these filepaths will return true from ' File.exist?(filepath)' - so why 'compare paths' when you can just 'check for existence' ?

Chris Fullmer

Yep, that's an easy fix to get around it. It never crossed my mind that the paths might return differently based on how I opened Sketchup, so it just threw me for a loop when something was working one way for so long suddenly started doing something else.

Dan Rathbun

This is a BUG.

And it can cause problems for file/plugin managers etc.

I tried manually fixing it using regedit but as soon as Sketchup starts up via a icon click, it resets the registry value back to the old 16bit format.

I noticed the value for "HKCR\Sketchup.KMZModel" has the correct format... but when I double-clicked a KMZ icon Google Earth opened instead.

Dan Rathbun

IMHO the double-click is unusable.

__FILE__ is not the only thing that gets messed up.

It also affects: Sketchup.find_support_file, Sketchup.find_support_files, Sketchup.get_resource_path, Sketchup.template_dir, and $LOAD_PATH

Here's a test script (put it "Plugins/_test" and run it both after a normal startup, and a double-click startup):
FILE.rb

I will not be surprised if some utility script chokes when Sketchup starts via double-click.

thomthom

@chris fullmer said:

Clearly the same path per se. But the string is not comparable. So don't rely on simple path string comparison on loading without being aware that the sting will not always be the same.

What is you use File.expand_path( __FILE__ ) before comparison ?

Dan Rathbun

@thomthom said:

@chris fullmer said:

Clearly the same path per se. But the string is not comparable. So don't rely on simple path string comparison on loading without being aware that the sting will not always be the same.

What IF you use File.expand_path( __FILE__ ) before comparison ?

It has no effect.. ie, does not correct the paths.

TIG

How about trying
File.identical?(string_file_path_to_check, __FILE__) ?
To compare against a preset string and another passed path.
If I understand it right... if the two arguments both point at the same file then irrespective of their actual 'strings' you'll get ' true' ?

OR even more simply File.file?(string_file_path_to_check) or File.file?(__FILE__) to check that the specified file exists and that it is a file and not a directory [if it's a directory use Dir.exist?() OR File.exist?()]

Dan Rathbun

The issue is not whether the file exists.. it does, because we are inside the file itself eval'ing __FILE__.

The issue is, that we wish to test if THIS __FILE__'s absolute path is identical to some other absolute path. Often the test will involve stripping off the filename.

The average plugin may not run into any problems with this bug, but a plugin / file manager like Smustard Organizer, or Dana Woodman's Installer, may have problems.

Dan Rathbun

TIG's suggestion DOES work !!!

File.identical?("C:/Program Files/Google/Google SketchUp 8/Plugins/testfile.rb", "C:/PROGRA~1/Google/GOOGLE~3/Plugins/testfile.rb")

true

Then, stripping off the filename and testing dir against dir:
File.identical?("C:/Program Files/Google/Google SketchUp 8/Plugins", "C:/PROGRA~1/Google/GOOGLE~3/Plugins")

true

But it's still stupid, that the installer writes 32 bit quoted pathname, and the app overwrites it each time it starts up with a 16bit pathname.
If I start SU7, i wonder if it will overwrite the registry key. Bet it will...