WebDialog set_file
-
Edit 3/1/10:
A better way to handle the problem (setting an HTML file to the same directory as the Ruby file), that works on Macs and PCs, and works however the Ruby was loaded is this:
pathname = File.expand_path( File.dirname(__FILE__) ) pathname = File.join( pathname, 'whatever.html' ) wd.set_file( pathname )
The
File.expand_path()
method returns the full path, back to the root on a Mac or back to the drive on a PC.end edit
Edit:
To shorten a long story, WebDialog.set_file() requires a drive specification or it won't work on Windows. This little bit of code does the trick:
def fixup( pathname ) =begin On a PC, WebDialog.set_file() requires a drive specification. 47 == '/' ( if working dir starts with '/' you're on a mac ) 58 == ';' ( don't add the directory, if you've already got one ) dir[0..1] on Windows will be 'C;' or 'D;' or ... =end dir = Dir;;pwd() # working directory pathname = dir[0..1] + pathname unless ( dir[0] == 47 ) || ( pathname[1] == 58 ) return pathname end
End edit.
I'm trying to distribute my little movie.
It uses a WebDialog for a "title" before the movie and another for "credits" after the movie. On my machine these are hard-coded. I want to soft code them.
The distribution .zip will include .skp files, .html for the dialogs, .rb code, etc. To keep life simple, I want them all to live in a single subdir that viewers can put anywhere convenient on their own machines. A "load /my/dir/airshow.rb" in the Ruby Console gets things started.
Problem is, I can't open the !@#$ html files with the
set_file()
method. Here are some things that don't work:wd.set_file( 'title.html' ) wd.set_file( File.dirname(__FILE__) + 'title.html' ) wd.set_file( File.dirname(__FILE__) + '/title.html' ) wd.set_file( 'title.html', File.dirname(__FILE__) ) wd.set_file( 'title.html', File.dirname(__FILE__) + '/' ) wd.set_file( File.dirname(__FILE__) + '/title.html', nil )
I even tried using
set_html()
but that lost the graphics that are a big part of the title.Edit: this works
pathname = Sketchup.find_support_file( 'title.html', '../../' + File.dirname(__FILE__) + '/' ) wd.set_file( pathname )
Somebody PLEASE tell me that there's a better way. I've fired people for writing code like that.
-
It appears your html file is two folders higher in the hierarchy than /plugins.
How smart do you think find_support_file (or set_file) is?
-
@martinrinehart said:
wd.set_file( 'title.html' )
wd.set_file( File.dirname(FILE) + 'title.html' )
wd.set_file( File.dirname(FILE) + '/title.html' )
wd.set_file( 'title.html', File.dirname(FILE) )
wd.set_file( 'title.html', File.dirname(FILE) + '/' )
wd.set_file( File.dirname(FILE) + '/title.html', nil )Have you outputted the full path you get from these variations to the console - visually verifying the path you're getting?
-
I think the problem is the API is not right (or explaining things the way they work.)
Sketchup.find_support_file and Sketchup.find_support_files do not return the same format.
One return a pathname with the Rubyish forward slash as file separator.
The other returns a Win32 like pathname with escaped backslashes, ie 'C:\Program Files\Google' etc.The example for WebDialog.set_file is showing:
dialog.set_file "c:\\mypage.html"
The only other thing I'd recommend is NOT using + to concat pathnames.
Use the Ruby function File.join whenever possible if forwardslash is to be the file separator. -
Excuse me for being a simpleton but why don't you just make the plugins folder the root; after all most people are used to extracting ruby things to the plugin folder.
-
@dan rathbun said:
I think the problem is the API is not right (or explaining things the way they work.)
Amen, brother.
From the console I conclude that the key is "C:".
File.dirname( ... )
does not return "C:". Absent the "C:"set_file()
can't find the file. Adding "C:" myself means there is 0% chance of working on a Mac. Therefore,find_support_file()
is a necessity to open an .HTML file in the same directory as the code. -
@chrisglasier said:
Excuse me for being a simpleton ...
I like simple. Simple is good.
I don't think
c:/Program Files/Google/Google SketchUp 7/Plugins/airshow
is simple. On my machine the airshow is/models/airshow
. I wanted your machine to have/yourchoice/airshow
.With a little Mac help, we may yet get there.
-
I'm not seeing that.
Test File: tt_file.rb
puts __FILE__.inspect puts File.dirname(__FILE__).inspect puts File.split(__FILE__).inspect
load 'tt_file.rb' "C:/Program Files (x86)/Google/Google SketchUp 7/Plugins/tt_file.rb" "C:/Program Files (x86)/Google/Google SketchUp 7/Plugins" ["C:/Program Files (x86)/Google/Google SketchUp 7/Plugins", "tt_file.rb"] true
-
I'm one who would have to disagree with your thoughts on simplicity here Martin. I can't stand things installing themselves into my c:\ root. I've come to appreciate the simplicity of knowing that all programs should be installed in the Program Files directory, instead of having to track them down in the root folder, among all the other non-program folders that already exist there.
-
But making your plugin work from wherever it's installed and anyone can install it wherever they may like.
-
That is ideal for sure!
-
@thomthom said:
I'm not seeing that.
Test File: tt_file.rb
> puts __FILE__.inspect > puts File.dirname(__FILE__).inspect > puts File.split(__FILE__).inspect >
load 'tt_file.rb' "C:/Program Files (x86)/Google/Google SketchUp 7/Plugins/tt_file.rb" "C:/Program Files (x86)/Google/Google SketchUp 7/Plugins" ["C:/Program Files (x86)/Google/Google SketchUp 7/Plugins", "tt_file.rb"] true
Now we're getting someplace! This is what I see:
(When you have to use screen shots to rule out the use of hallucinogenic drugs, you know you've got a problem.) "Tell me what's goin' on - I ain't got a clue!" J. Buffett
-
@chris fullmer said:
... I can't stand things installing themselves into my c:\ root. I've come to appreciate the simplicity of knowing that all programs should be installed in the Program Files directory, ...
I am sure of fewer and fewer things as I get older. Some because I forget, others because I question old certainties. But one thing I hold true:
Where you put stuff on your computer should always be your choice, not mine.
-
Yup, as I stated above too, that is also what I prefer. I thought it looked like you were fixing to force installation to a fixed location with this.
-
File.dirname( File.expand_path(__FILE__) )
Seems that
__FILE__
didn't return an absolute path when you skipped the in your path -
@thomthom said:
Seems that
__FILE__
didn't return an absolute path when you skipped the in your pathBingo!
A few more experiments, a Mac answer and then maybe a sensible
set_file()
. Maybe I won't have to fire myself! -
One other idea is to use the File class to get the string from the file, and then use set_html.
-
@cjthompson said:
One other idea is to use the File class to get the string from the file, and then use set_html.
Then everything the HTML file links to will be relative to a random temp folder - which can cause problems unless you use absolute URIs for everything. Or include a
<base>
tag. -
Edited solution into original post. Zero reported problems from movie viewers, so maybe it works.
-
@dan rathbun said:
Found the problem on PC.
It's a boo-boo using the File.join method. An extra SEPARATOR is getting inserted at the beginning of the URL string, so that whatever the pathname, whether you use the optional relative path (2nd argument) or not, the resulting URL passed to the browser begins with:
file:///file:///
is a valid URI. http://en.wikipedia.org/wiki/File_URI_scheme#WindowsFirefox diplay local URIs like that. IE will open such URI and convert it into what you see in Windows Explorer. So odd that it'd be problems with the webdialog then.
Advertisement