WebDialog.set_html fails under Safari 5.0.6

[thomthom]

@driven said:

@unknownuser said:

@thomthom said:

The question I had on temp file is whether the html file should absolutely be in the ENV["TMPDIR"] folder or in any folder (like /tmp)

Fredo

I just did a test and

@tempfile = File.join( "/Library/Application Support/Google\ SketchUp\ 8/SketchUp/plugins/TT_Lib2/webdialog", filename )

runs the same as the former, but I can find it easier...

If the file is in the system temp then it's more likely that stray files will be removed.

@driven said:

another thing...

I decided to check the html temp files from both paths to see if they where identical (they are)

I also get this identical message when opening in TextWrangler.

temp_file_message.png
temp_file_message.png (47.92 KiB) Viewed 4 times

never seen that for any other html files, so I checked Fredo's tmp htmls as well and they are fine.

That's because I have sent a ³ character in ANSI format instead of UTF-8. It's nothing important.

[driven]

if your proxy is in your webdialog folder, all your links are then relative... I'd vote for that... if I can

[thomthom]

@unknownuser said:

@thomthom said:

Cursed - this is more troublesome than I thought.
Under Windows I can clean up all temps by using AppObserver.onQuit - but under OSX it appear to never trigger.

You should not worry too much with the temporary file.
You create it with a unique name and then delete it when you close the dialog box (I guess you have a hook in the on_close() event).

w = WebDialogPatch.new( 'Hello World' ) w.show w.set_html( 'Lorem Ipsum' ) w.close w.show # HTML file would now be missing...

[thomthom]

@driven said:

if your proxy is in your webdialog folder, all your links are then relative... I'd vote for that... if I can

[fredo6]

@thomthom said:

I'm thinking I might not need temp files at all. I just need to send the HTML to the webdialog via .execute_script to a proxy HTML document that replaces the content.

I remember that execute_script suffered from a string size limitation on Mac?
Maybe this is fine now.

Fredo

[driven]

@thomthom said:

I'm thinking I might not need temp files at all. I just need to send the HTML to the webdialog via .execute_script to a proxy HTML document that replaces the content.

by proxy HTML document I assumed you meant a html file that is basically populated by your current window.html + ruby, which is then sent to web dialog and is then updated via ruby.

if that's what you mean, and it lived beside window.html can't all your links then be relative i.e. href=css/ui.css, src=js/base.js, etc...

john

[thomthom]

@unknownuser said:

@thomthom said:

I'm thinking I might not need temp files at all. I just need to send the HTML to the webdialog via .execute_script to a proxy HTML document that replaces the content.

I remember that execute_script suffered from a string size limitation on Mac?
Maybe this is fine now.

Fredo

Arrgh - yea I've heard rumors about that. Cursed how troublesome the WebDialog should be under OSX!

@driven said:

if that's what you mean, and it lived beside window.html can't all your links then be relative i.e. href=css/ui.css, src=js/base.js, etc...

Yes. In fact, I made them relative in 2.5.5 because they relied on the BASE tag in the header which pointed everything to the root dir of the webdialog.

[Dan Rathbun]

@unknownuser said:

I remember that execute_script suffered from a string size limitation on Mac?

Well there's always injecting a external script file.

dlg.execute_script %[
  var xx = document.createElement('script');
  xx.type = 'text/javascript';
  xx.src = "file;//some/path/to/script.js";
  document.getElementsByTagName('head')[0].appendChild(xx)
]

[thomthom]

@dan rathbun said:

@unknownuser said:

I remember that execute_script suffered from a string size limitation on Mac?

Well there's always injecting a external script file.

dlg.execute_script %[
>   var xx = document.createElement('script');
>   xx.type = 'text/javascript';
>   xx.src = "file;//some/path/to/script.js";
>   document.getElementsByTagName('head')[0].appendChild(xx)
> ]

But we wanted to send the HTML itself to the webdialog for replacement as a way to avoid temp files.

[Dan Rathbun]

Right ok.. same kind of deal.

assume you have a block of html text in Ruby htmltext

1. You open the dialog with a blank body template using set_file()

2. Then create a Js var called bodytext (as above)

3. Successively...
   ... take chucks of htmltext and assign to htmlpart
   ... and use execute_script("body_text += '#{htmlpart}'")
   .. or similar until all the Ruby-side text has been transfered.

4. then call execute_script("document.body.innerHtml=body_text;")

[thomthom]

Yea, I was planning on adding a large data pump to my library anyway. But I need to work out what the data limit is... Hopefully I can just send a very large string from ruby and compare it in JS.

[thomthom]

Actually, what I really hope for is that at_exit works under OSX.

[Dan Rathbun]

@thomthom said:

Cursed - this is more troublesome than I thought.
Under Windows I can clean up all temps by using AppObserver.onQuit - but under OSX it appear to never trigger.

So then there's no way under OSX that my proposed workaround for the Instance Observer can work for SU8.

Makes me wonder if "they" just turned off the onQuit() callback (for OSX,) as a 'quick-temporary-fix' for the BugSplat! on close issue?

[thomthom]

@dan rathbun said:

Makes me wonder if "they" just turned off the onQuit() callback (for OSX,) as a 'quick-temporary-fix' for the BugSplat! on close issue?

hm... when was that fix issued? I'd like to try with an older SU to check.

[Dan Rathbun]

@thomthom said:

@dan rathbun said:

Makes me wonder if "they" just turned off the onQuit() callback (for OSX,) as a 'quick-temporary-fix' for the BugSplat! on close issue?

hm... when was that fix issued? I'd like to try with an older SU to check.

I am speculating... remember during v8 beta the Instance Observer OSX BugSplat! on close without saving the model first?
It was not fixed for 8.0M1.

However you have that onQuit() works for v7.1 on OSX.

[thomthom]

I tried onQuit and at_exit on OSX SU 7.1.6859 and I could not get them to trigger either...

[Dan Rathbun]

It's a bit confusing to have your Observer table combined with both platforms, have you thot about having a table for each platform?

[Dan Rathbun]

And just to be clear, your testing using the Ruby ver that ships with the Sketchup version? (v1.8.5-p0)

What happens if your change the Sketchup Ruby symbolic links on the Mac to a newer Ruby install (v1.8.6-p287 or higher?)

[Dan Rathbun]

And also you might try to trap the SystemExit exeception, which is supposed to be called, unless Google used exit!() in which case your out of luck.

I'm not sure if Kernel.set_trace_func will catch a call to exit!() or not.

[thomthom]

@dan rathbun said:

It's a bit confusing to have your Observer table combined with both platforms, have you thot about having a table for each platform?

Wouldn't having two tables make it harder to get an overview of what observers has issues?

@dan rathbun said:

And just to be clear, your testing using the Ruby ver that ships with the Sketchup version? (v1.8.5-p0)

What happens if your change the Sketchup Ruby symbolic links on the Mac to a newer Ruby install (v1.8.6-p287 or higher?)

Yes - I only test SketchUp out of the box. And that is complicated and time-consuming enough...