WebDialog set_file

chrisglasier

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.

MartinRinehart

@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.

MartinRinehart

@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.

thomthom

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

Chris Fullmer

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.

thomthom

But making your plugin work from wherever it's installed and anyone can install it wherever they may like.

Chris Fullmer

That is ideal for sure!

MartinRinehart

@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

MartinRinehart

@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.

Chris Fullmer

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.

thomthom

File.dirname( File.expand_path(__FILE__) )

Seems that __FILE__ didn't return an absolute path when you skipped the in your path

MartinRinehart

@thomthom said:

Seems that __FILE__ didn't return an absolute path when you skipped the in your path

Bingo!

A few more experiments, a Mac answer and then maybe a sensible set_file(). Maybe I won't have to fire myself!

cjthompson

One other idea is to use the File class to get the string from the file, and then use set_html.

thomthom

@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.

MartinRinehart

Edited solution into original post. Zero reported problems from movie viewers, so maybe it works.

thomthom

@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#Windows

Firefox 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.

thomthom

ah. .set_file was passed the URI. now I see.

Dan Rathbun

@thomthom said:

ah. .set_file was passed the URI. now I see.

No I thought .set_file was doing this:

def set_file(filename, path='') %(#F0F0F0)[__]protocol='file://' %(#F0F0F0)[__]set_url( File.join(protocol,path,filename)) end

But Ruby's File.join is actually kinda smart. Google may have used their own dumb version that adds extra /s.

But I'm not sure:

my_dialog.set_file('C:/scite/WebDialogTips.html','')
Works

my_dialog.set_file('C:/scite/WebDialogTips.html')
Works

my_dialog.set_file('WebDialogTips.html','C:/scite')
Error ('Cannot Load Webpage' Error Webpage, but NOT MSIE Error dialog.)

my_dialog.set_file('WebDialogTips.html','C:/scite/')
Works

EDIT NOTE: For this test, I copied file 'WebDialogTips.html' into 'C:/scite/' because the sciTE folder is in my System PATH (not my Ruby $LOAD_PATH.)

my_dialog.set_file('WebDialogTips.html','')
and
my_dialog.set_file('WebDialogTips.html')
both produce the MSIE Error Dialog, that says:
"Cannot find 'file:///WebDialogTips.html'. Make sure the path or Internet address is correct."

So the Win System PATH makes no difference.
_

Dan Rathbun

@thomthom said:

file:/// is a valid URI. http://en.wikipedia.org/wiki/File_URI_scheme#Windows

Firefox 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.
Yes 3 slashes work if I paste it into the addressbar of a normal MSIE browser.
But for WebDialog, on PC (Win32),
where path=Sketchup.find_support_file(''):

my_dialog.set_url('file://localhost/'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file:///localhost/'+path+'/Support/webpage.html')
Error

my_dialog.set_url('file:////localhost/'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file://///localhost/'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file://////localhost/'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file://localhost//'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file:///localhost//'+path+'/Support/webpage.html')
Error

my_dialog.set_url('file:////localhost//'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file://///localhost//'+path+'/Support/webpage.html')
Works

my_dialog.set_url('file://////localhost//'+path+'/Support/webpage.html')
Works

Any more than 6 /'s before localhost or 2 following, does not work for WebDialog.

Dan Rathbun

UI::WebDialog.set_file
BUG found

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:///

For this test I have Rick Wilson's lil' html help file in the Support folder:
Rename it to .html and put it in the Sketchup Support folder

my_dialog=UI;;WebDialog.new('Smustard Organizer Compatibility',true,'test',800,600,100,100,true)
SUpath=Sketchup.find_support_file('') #empty string needed!
my_dialog.set_file('Support/Smustard_Organizer.html',SUpath)
my_dialog.show

On the PC this results in MSIE error dialog stating that 'Internet Explorer cannot find the file:
"file:///C:/Program Files/Google/Google SketchUp 7/Support/Smustard_Organizer.html"_'
Trying various combinations of the set_file method: 1 argument, 2 arguments, etc., I have also been able to get 2 types of error webpages, 'Internal Server Error' and the normal useless 'Cannot Open the Webpage error' with the likely reasons ie: No Internet connection, etc.

LESSON
UseUI::WebDialog.set_url instead.

my_dialog=UI;;WebDialog.new('Smustard Organizer Compatibility',true,'test',800,600,100,100,true)
SUpath=Sketchup.find_support_file('') #empty string needed!
# Remove leading file separator on Mac (or Win without Drive;) 
SUpath.slice!(0,1) if SUpath[0,1]==File;;SEPARATOR
# File.join will put it back in
my_dialog.set_url( File.join('file;//localhost',SUpath,'Support/Smustard_Organizer.html'))
my_dialog.show

It is quite likely that .set_file actually just calls .set_url passing the latter improperly concatenated pathname string portions misusing the File.join method. (Obviously the set_file method could be fixed using the slice! technique above.)

UI.openURL
The same technique can (and should) be used with UI.openURL so that code is cross-plaform.

On Mac, testing has shown that OSX wants 'file://localhost' at the begining of the URL or it can't find the file.* On PC, Windows will adjust the URL, stripping off the 'file://localhost' and passing the rest of the path to whatever application is registered for the file extension. (Not always the browser.)

WebDialog.new
Two things to note here.

Comma Separated Parameter List form: IF the pref_key argument is nil or '' (empty string), the remaining arguments are ignored. (This is why I set the key to 'test' in the examples above.) So if you are attempting to make a WebDialog that does not save settings, and it is not showing at the position and size you want, this may be why.

Hash as Parameter form: Contrary to what has been said that the dialog_title parameter cannot be set through the hash, it CAN be. However, there is a bug in this new Hash based functionality. In that the Google coder did not take into account that there are several ways of defining a Hash, ie, with Symbol keys or String keys. The coder should have just converted each key using to_s and then made the value assignments based on the keystring, but didn't. So the Hash based form is 'quirky'. You must use Symbolsas keys, NOT Strings:
hsh=Hash[:dialog_title=>'Title passed by Hash', :scrollable=>false, :preferences_key=>'MyDialog', :width=>800, :height=>600, :left=>100, :top=>100, :resizable=>true]
AND once again if you omit the :preferences_key value pair, it seems the remaining arguments are ignored.. ie default position is 0,0 and size is 250,250 instead of those specified in the hash.

Conclusion: Because of the kwappy way the WebDialog API was coded, we must pass ALL parameters or Hash keys (which actually defeats the advantage of the Hash, over a Comma Sep'd Parameter List.)
_