WebDialogs - The Lost Manual — R1 09 November 2009

WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Sun Nov 08, 2009 7:42 pm

Revision: R1 - 09 November 2009




This topic is outdated!

In order to better maintain The Lost Manual I am moving it from a long single page PDF/forum post/blog article to a better structured GitHub repository with Wiki articles detailing issues, how-to and best practices as well as sample files and Issue tracker.

It's still rough around the edges as information is ported from the old manual and lingering notes, but please join in on the contribution and share your insight! Get your fork out!


https://github.com/thomthom/sketchup-we ... ost-manual




I've recently been working more with WebDialogs and I have noticed there's a great deal of got-cha's which is not mentioned in the documentation, which you can find buried in this forum. Therefore I want to collect all this info into one single post where all the important stuff is in the top - not scattered in various threads or buried deep in a topic. Please drop me a message or add a comment to this thread for more information to add.

Overview

  • Cross Platform
    • Async vs sync Communication
    • window.onload
    • WebDialog.show / WebDialog.show_modal
    • Quirks vs Standard vs Superstandard
    • HTML, CSS and Javascript
  • WebDialog.new
    • Comma Separated Arguments
    • Hash argument
    • Fixed window size
    • Scrollbars
  • Paths - WebDialog.set_file vs WebDialog.set_html
  • Bugs and Issues
    • OSX .execute_script and quotes
    • WebDialog Javascript callback Maximum message size
    • #<Exception: Invalid Dialog>
    • <LocalJumpError: return from proc-closure> in WebDialog
  • Debugging
  • Thanks


Cross Platform

Async vs sync Communication
On PC the communication between javascript and ruby is synchronous. That means when you call a ruby method using window.location = 'skp:rubyMethod', the javascript will wait for the ruby method to complete before proceeding with the next javascript statement.

On OSX it just sends the command and continues with the javascript without waiting - making it impossible call sequential callbacks to ruby too quickly as they will override each other.

Calling from ruby to javascript using .execute_script is synchronous on both platforms. The method will wait for the javascript to finish before processing next line of ruby.

So you can do stuff like this:
Code: Select all
dialog.execute_script('add(2,3);')
value = dialog.get_element_value('sketchupPump')


The add javascript function will here take both arguments and add them together and put the value into a hidden input field with the id 'hidden_input'.
Code: Select all
function add(n1, n2)
{
    document.getElementById('sketchupPump').value = n1 + n2;
}


The input field in the HTML is something like this:
Code: Select all
<input id="sketchupPump" type="hidden">


Further reading:


window.onload
On Windows, the HTML document appear to be created when you call dialog.show. If you attach an event to window.onload which send a command back to ruby to print "Hello World" in the console you'll see "Hello World" printed as you call .show. But on OSX it seems that the HTML document is created as you use .set_file or .set_html - before calling .show.
Example script:
Code: Select all
module TT_Test
  @d = nil
  @d = UI::WebDialog.new('On Load Test')
  @d.add_action_callback('onload') { |dialog, params|
    puts '>> window.onload'
  }
  @d.set_html('<html><body onload="window.location=\'skp:onload\';">Onload Test</body><html>')
  def self.onload
    @d.show {
      puts '>> ruby block'
    }
  end
end


On Windows, when you run the script:
load 'test/webdialog.rb'
true
TT_Test.onload
true
>> ruby block
>> window.onload


Notice that the ruby block executes before the WebDialog onload event, which might indicatethe block is run before the HTML document is ready.
On OSX:
> load 'test/webdialog.rb'
true
>> window.onload
> TT_Test.onload
true


Notice that window.onload triggers immediately as we've added the HTML to the WebDialog object. And that the .show block never executes.

So if you create a WebDialog object when you load your plugin, beware that it will consume resources from the moment you add the HTML and not wait for the dialog to actually show.


WebDialog.show / WebDialog.show_modal
On OSX, .show_modal only makes the window stay on top of the Sketchup window, but the window is not really modal.

On PC the window always stays on top of Sketchup, but .show_modal is truly modal.
It also seems that when you pass a block along with .show or .show_modal, the block will never execute on OSX.


Quirks vs Standard vs Superstandard
When you create a HTML document, it behaves differently depending on the DOCTYPE you choose. You must choose the DOCTYPE you want to work with. For further reading: http://www.quirksmode.org/css/quirksmode.html

Note! Because WebDialogs are embedded browser controls they behave differently than a normal website on Windows. Internet Explorer 8, as a browser, will default to Super Standard mode when you use Strict DOCTYPE. But when embedded as a WebBrowser object it will default to IE7 compatibility mode. Microsoft says that you have to set a registry key for the application that embeds the WebBrowser to make it use IE8 rendering mode. But of course we can't do that for Sketchup since some plugins might rely on the IE7 mode.

But what you can do is include the meta tag <meta http-equiv="X-UA-Compatible" content="IE=8"/>. Note that this meta tag should be placed at the top of the <head> tag.

Beware that the user agent string will still report MSIE 7.0 for embedded WebBrowsers - even though you use IE8 mode. This differs from when you test the same HTML in the normal web browser where it returns MSIE 8.0. To check the rendering mode: document.documentMode.


HTML, CSS and Javascript
Personally I use Strict DOCTYPE as it render more consistently between platform.

To simplify javascript work I use jQuery which is a lightweight framework that let you quickly manipulate the DOM and deal with events in a manner where you don't have to concern yourself much about differences between the platforms.

For in introduction to HTML and CSS I recommend HTML Dog. It's up to date and will recommend best practices. http://htmldog.com/

For lookup references to most web related languages: http://www.w3schools.com/

The ultimate reference to web standards: http://www.w3.org/


WebDialog.new
You can specify the arguments as either a comma separated list, or as a single Hash object. Currently the manual is missing information for both of these.

Comma Separated Arguments
  • dialog_title The title to be displayed in the webdialog.
  • scrollable true if you want to allow scrollbars, false if you do not want to allow scrollbars.
  • pref_key The registry entry where the location and size of the dialog will be saved. If preferences_key is not included, the location and size will not be stored.
  • width The width of the webdialog.
  • height The height of the webdialog.
  • left The number of pixels from the left.
  • top The number of pixels from the top.
  • resizable true if you want to allow the window to be resize by the user.


Hash argument
Code: Select all
keys = {
    :dialog_title => title,
    :scrollable => false,
    :preferences_key => 'MyDialog',
    :height => 300,
    :width => 400,
    :left => 200,
    :top => 200,
    :resizable => true,
    :mac_only_use_nswindow => true}
@dialog = UI::WebDialog.new(keys)


But the hash exposes a new undocumented argument, :mac_only_use_nswindow.


Fixed window size
When you specify position and size Sketchup only uses those values the first time you create the dialog. After that it reads the last used values from the registry. That might be want to you want for resizable windows. But maybe not for windows with a fixed size which the user can't resize.

When you develop a plugin you might find that you need to change the size of your fixed size window, but you can't see the effect because Sketchup just reads your last values. In which case you need to delete the registry settings for your Webdialog, or use the .set_size method after you create the fixed size window to ensure the correct size.

And if you do not specify a preference key, Sketchup seem to disregard both size and position.


Scrollbars
The scrollbar argument does not seem to work on PC. In order to disable the scrollbars you must set a CSS property. What HTML to assign this property to depends if your HTML uses Quirks Mode or Standards Mode.

If you're using Quicks Mode you assign it to the BODY element:
body { overflow: hidden; }

If you are using Standard Mode you assign it to the HTML element:
html { overflow: hidden; }

This is because the effective root element in an HTML document differs from Quicks to Standards Mode.


Paths - WebDialog.set_file vs WebDialog.set_html
When you use .set_file to populate the HTML document, all resources (images,CSS,scripts etc.) will be relative to the file you specify.

But when you use .set_html, all resources are relative to a temp file created on the system. So if you need to reference external resources from the HTML, either use absolute paths, or add a <base> tag to the <head> of the <html> - specifying where relative paths should be resolved from:
<base href="c:/absolute/path/" />


Bugs and Issues
OSX .execute_script and quotes
There was some issues with .execute_script and quotes in Sketchup prior to 7.0 on OSX. http://forums.sketchucation.com/viewtop ... 316#p49259

WebDialog Javascript callback Maximum message size
The Javascript callback to ruby has a size limitation. When sending data back to ruby it's better to store the data in a hidden input field and use .get_element_value. http://forums.sketchucation.com/viewtop ... 683#p52107

#<Exception: Invalid Dialog>
Unknown error. Caused by BoundingBox? http://forums.sketchucation.com/viewtop ... 67#p190035

<LocalJumpError: return from proc-closure> in WebDialog
Issues with using return in callback methods from Javascript? Think I've experience this myself. http://forums.sketchucation.com/viewtop ... 22#p185099


Debugging
You can use Firebug Lite to help debugging your HTML+JS in WebDialogs.
http://getfirebug.com/lite.html


Thanks
Thanks to everyone on SCF that has contributed with their share of this collective knowledge.
0
Last edited by thomthom on Mon Nov 09, 2009 10:56 pm, edited 1 time in total.
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs – The Lost Manual

Postby tomot » Mon Nov 09, 2009 8:13 pm

greatly appreciated!
0

tomot 
PluginStore Author
PluginStore Author
 

Re: WebDialogs – The Lost Manual

Postby thomthom » Mon Nov 09, 2009 8:21 pm

Note to self: Update Async vs sync Communication
It's not .execute_script that's async - it's the Javascript callback using the skp: protocol
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs – The Lost Manual

Postby Jim » Mon Nov 09, 2009 9:01 pm

Thanks for doing this Thomas.
0
Hi

Jim 
Global Moderator
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Mon Nov 09, 2009 10:57 pm

Revision 1
Updated info about async vs sync behaviour.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby MartinRinehart » Tue Nov 10, 2009 12:36 am

:thumb: :thumb: :thumb:
0
Author, Edges to Rubies - The Complete SketchUp Tutorial at http://www.MartinRinehart.com/models/tutorial.

MartinRinehart 
 

[WebDialog] - The Lost Manual — R1 09 November 2009

Postby chrisglasier » Tue Nov 10, 2009 1:06 am

Finally, there is a difference in the way that the Mac boots up SketchUp that you should be cautious about: there is no Sketchup.active_model when the Ruby scripts are first loaded. So if your script is making changes to the active_model at load time, it will not work on the Mac. The answer? Ensure code that references the active model is part of a UI event handler, responding to the user selecting a tool or a menu item. You can also use an AppObserver to get a callback whenever a new model is opened, at which point it's safe to talk to the active_model.


I didn't see this anywhere. I don't remember where it comes from.

How about marking topics and posts with [WebDialog]?

Good work - most generous with your time.

Chris
0
With JSON machines we can analyse what is to be achieved so that IT can help with automation to achieve it.
User avatar
chrisglasier 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Tue Nov 10, 2009 8:43 am

I hope that people will point out things that are not clear. Writing has never been my strongest skill, actually - its one of my poor, so please point out the weaknesses.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby tomasz » Tue Nov 10, 2009 11:04 am

Thank you!
0

tomasz 
SU2TH & SU2KT Developer
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby Jernej Vidmar » Sun Nov 15, 2009 11:11 pm

Hi Thom,

thanks for sharing this really usefull information!

Just as a side note:
We have found a bug, which cuts decimal value sent from SketchUp to WebDialog (only in SU6 on Mac). If we i.e. want to update the value of some input box like this:
web_dialog.execute_script("updateInputBox('varName', '12,345')")
only 12 is shown in the varnName inputbox, everything behind (and including) comma is being cut off. But it works in SU7 on Mac and on both, 6 and 7 versions of SU on Windows.
0

Jernej Vidmar 
Modelur
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Sun Nov 15, 2009 11:28 pm

Ah, is that whatæs being mentioned in the release notes: http://code.google.com/apis/sketchup/docs/releases.html
Fixed Mac support for WebDialogs execute_script
Code: Select all
WebDialog.execute_script('alert("Bug is Fixed!")');


Does it work if you escape the comma? If not, replace it with another character?
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby Jernej Vidmar » Mon Nov 16, 2009 2:05 am

No, escaping doesn't seem to help. Only way to pass the float value is to write it using dot (1.12) not comma (1,12)...
For now we have not found a workaround, but we intend to make some more tests to see if the problem can be bypassed.
0

Jernej Vidmar 
Modelur
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Mon Nov 16, 2009 8:44 am

I wonder, if you make a special receiving javascript function, and send all command base64 encoded to that function and have it decode and eval it..?

Code: Select all
# made up methods - haven't checked the real methods
jscall = base64encode("updateInputBox('varName', '12,345')")
WebDialog.execute_script("decode(#{jscall})");

Code: Select all
function decode(base64str)
  eval(decode64(base64str));
end
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby DIEGO-RODRIGUEZ » Fri Dec 04, 2009 5:33 am

0

DIEGO-RODRIGUEZ 
Banned
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Fri Dec 04, 2009 8:32 am

You won't be able to use HTML5 in webdialogs - not until IE adds support for it. Think I read somewhere that they where adding support for it in IE9. Being able to use CANVAS sure would be nice.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby tbleicher » Sun Jan 24, 2010 6:15 pm

thomthom wrote:You won't be able to use HTML5 in webdialogs - not until IE adds support for it.


I am using excanvas http://code.google.com/p/explorercanvas/ which provides a canvas object in IE.

Thomas
0

tbleicher 
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Sun Jan 24, 2010 6:17 pm

tbleicher wrote:
thomthom wrote:You won't be able to use HTML5 in webdialogs - not until IE adds support for it.


I am using excanvas http://code.google.com/p/explorercanvas/ which provides a canvas object in IE.

Thomas

That's very interesting! I've been wanting for a good solution to dynamically draw graphics in webdialogs. Probably be of interest for Whaat as well... ...thinking Profile Builder...
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby Jim » Sun Jan 24, 2010 6:50 pm

And just to have more options, there is also chrome frame.
0
Hi

Jim 
Global Moderator
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Sun Jan 24, 2010 7:13 pm

Jim wrote:And just to have more options, there is also chrome frame.

Yea, but this requires the user to install a browser plugin.
explorercanvas is a simple JS library which the developer includes in the project without the user ever having to install any browser extension. That's what's appeal to me.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby Pout » Thu Jan 28, 2010 3:05 pm

this seems to be very interesting
Have to dig into this.
0

Pout 
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby chrisglasier » Mon Mar 15, 2010 12:38 pm

One thing driven discovered was that if for some reason there is whitespace as here -


Code: Select all
cmd = "fImportReturn('#{array}');"
@dlg.execute_script (cmd)

instead of

@dlg.execute_script(cmd)



it is OK on PCs but not Macs. This maybe of interest to coders who use this style (Jim).
0
With JSON machines we can analyse what is to be achieved so that IT can help with automation to achieve it.
User avatar
chrisglasier 
PluginStore Author
PluginStore Author
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby Jim » Mon Mar 15, 2010 9:05 pm

Would a kind Mac user (or 2) open the Ruby Console, and give the result from entering:

$VERBOSE

and

$DEBUG

and

$-w
0
Hi

Jim 
Global Moderator
 

Re: WebDialogs - The Lost Manual — R1 09 November 2009

Postby thomthom » Mon Mar 15, 2010 10:21 pm

Jim wrote:Would a kind Mac user (or 2) open the Ruby Console, and give the result from entering:

$VERBOSE

and

$DEBUG

and

$-w


Code: Select all
> $VERBOSE
false
> $DEBUG
false
> $-w
false


SU 7.1.6859
OSX 10.4
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: $VERBOSE and $DEBUG

Postby Dan Rathbun » Tue Mar 16, 2010 11:46 am

Jim wrote: Would a kind Mac user (or 2) open the Ruby Console, and give the result from entering:

$DEBUG
The 'Pick-Axe' book says false is the default.

Jim wrote:$VERBOSE [alias] $-w
The 'Pick-Axe' book says false is the default and known as 'medium mode'.
When set to nil, it is 'silent mode'; when set to true, it is 'verbose mode'.

The reason for the $-w alias 'flag', is that $VERBOSE is [supposed to be] the conditional argument used by warnings. But, something's fishy..

(from Ruby.h, ver 1.8.6, line 562..564, Language="C" )
void rb_warning __((const char*, ...)); /* reports if `-w' specified */
void rb_sys_warning __((const char*, ...)); /* reports if `-w' specified */
void rb_warn __((const char*, ...)); /* reports always */


So.. rb_warn is NOT supposed to check $VERBOSE, and rb_warning IS.
What's weird is that the Ruby method Kernel.warn is documented as if it calls rb_warning, instead of rb_warn; and the Core RDoc actually gives two internal examples, one in Pure Ruby (see it) and one in C (see it) that are written to act like rb_warning is supposed to act. (Note, the C example is really named 'rb_warn_m'.)

But in practice... I find that Kernel.warn acts like rb_warn is supposed to act, and it does not matter what $VERBOSE is set to. The message is always sent to $stderr.

This has forced me to make my 'warn' calls work the way they should, by doing this:
# Send warning only if in Verbose mode
warn('My Informational Message') if $VERBOSE

# Send warning unless in Silent mode
warn('My Important Message') unless $VERBOSE.nil?

# Send warning no matter what Verbose mode
warn('My Critical Message that MUST be displayed!')

BUT.. I'm sick of doing this workaround!

I want to make three warn methods, that work the way they should.
Firstly, the current warn needs to be renamed old_warn (or something else.)
And define a replacement warn! that has typechecking, and returns true if no IO error occurs. (The original just returned nil.)
Then define a new warn, that displays (returns true,) unless in Silent mode (returns false.)
Third define a new warn?, that checks and only displays if $VERBOSE is true (and returns true, otherwise returns false.)
(If there's any problem with the $stderr IO object, an Exception should be raised by the object itself.)
Example Ruby override code: ### under REVISION to a Mix-In Module ###
Code: Select all
# file warn_ovr.rb

# Make Warnings work the way they should.
#
# by: Dan Rathbun - 16 MAR 2010 - Palm Bay, FL, USA
#
# TERMS: Public Domain

module Kernel  ##<<----<<< this will change in next Revision

  ### under REVISION to a Mix-In Module with a different module name

  # alias the old warn method
  alias_method(:old_warn,:warn)

  # warn! will always send to $stderr
  # regardless of $VERBOSE setting
  def warn!(msg)
    unless msg.is_a?(String)
      raise(TypeError,'String argument expected.',caller(1))
    end
    $stderr.write(msg + "\n")
    return true # no IO error occured
  end

  # warn will now send to $stderr
  # ONLY if $VERBOSE is not Silent mode (nil)
  def warn(msg)
    unless msg.is_a?(String)
      raise(TypeError,'String argument expected.',caller(1))
    end
    unless $VERBOSE.nil?
      $stderr.write(msg + "\n")
      return true
    else
      return false
    end
  end

  # warn? will send to $stderr
  # ONLY if $VERBOSE is in Verbose mode (true)
  def warn?(msg)
    unless msg.is_a?(String)
      raise(TypeError,'String argument expected.',caller(1))
    end
    if $VERBOSE
      $stderr.write(msg + "\n")
      return true
    else
      # We return false if $VERBOSE is nil or false
      return false
    end
  end

end # Kernel

EDIT: Code changed.
  • Sketchup has .puts as private, changed to using $stderr.write
  • cleaned up code a bit; more readable.
Question, I set raise to remove the last item from the callstack. Not sure if this is correct or not?
0
Last edited by Dan Rathbun on Fri Mar 19, 2010 5:57 pm, edited 2 times in total.
    I'm not here much anymore. But a PM will fire email notifications.
    User avatar
    Dan Rathbun 
    PluginStore Author
    PluginStore Author
     

    Re: Warnings

    Postby Dan Rathbun » Tue Mar 16, 2010 1:15 pm

    By the way.. we have no control over C-implemented Ruby objects, that incorrectly call the wrong C 'warn'/'warning' function, ie: don't respond to the setting of $VERBOSE ( called ruby_verbose in C.)

    If you find one, it would need to be reported on RubyForge.net
    0
      I'm not here much anymore. But a PM will fire email notifications.
      User avatar
      Dan Rathbun 
      PluginStore Author
      PluginStore Author
       

      Re: WebDialogs - The Lost Manual — R1 09 November 2009

      Postby chrisglasier » Thu Mar 18, 2010 3:01 am

      mmyoung wrote:
      I was never able to get Matt666's PointTool.rb to work on my Mac. I opened it in a text editor and removed the "=begin" and "=end" lines at the beginning and placed a "#" at the beginning of each comment.

      Now it runs on Mac.


      This may be relevant here as well.
      0
      With JSON machines we can analyse what is to be achieved so that IT can help with automation to achieve it.
      User avatar
      chrisglasier 
      PluginStore Author
      PluginStore Author
       

      Re: WebDialogs - The Lost Manual — R1 09 November 2009

      Postby driven » Fri Mar 19, 2010 3:57 pm

      chrisglasier wrote: This may be relevant here as well.


      hi,
      some Mac bits...

      @Jim I get false, false, false

      @Dan #!ruby warn_ovr.rb returns nil

      whitespace handling is strange, not consistent from script to script, some work with whitespace , but all work without it...

      the =begin; =end seems to be dependent on what editor the file was last saved in....

      I never had a problem if I had a look with xCode, but when I first used Smultron the syntax colouring for '=' commenting is off by default, and very oddly appears to effect how SU then sees some of the files saved from this state...

      It took a while to figure out, but all affected files worked after changing the syntax colouring option to on and re-saving. Re-saving from xCode also 'fixed' them, which was my only 'clue' of what was happening.

      Something that came up proof positive last week (and I'm trying to find a test for), is that not all Macs are handle syntax the same

      there was an issue with one of TIG's scripts and it seems that Mac's running Developer Tools have much stricter syntax prerequisite.

      I did a mini survey of systems 'failing' and we all had different mixes of OSX, Ruby, Gems, editors but all had DevTools

      a Variety of Macs without were fine but those with Xcode were failing to run the script, TIG found a solution for his script, but the consistency of the Pass/Fail leads me to think it may make a good test tool... when I know how...

      On another point anyone know of a .json to/from .skp or collada convertor for Mac?

      john
      0
      learn from the mistakes of others, you may not live long enough to make them all yourself...

      driven 
      PluginStore Author
      PluginStore Author
       

      Re: WebDialogs - The Lost Manual — R1 09 November 2009

      Postby Jim » Fri Mar 19, 2010 5:19 pm

      Just a small note mentioning a file-based dialog need not use the .htm or .html extension - any filename used in set_file will work.

      For example, this works just fine:

      @dlg.set_file("user_interface.dlg")

      Although clearly the contents need to be HTML, the filename extension does not matter.
      0
      Hi

      Jim 
      Global Moderator
       

      Re: WebDialogs - The Lost Manual — R1 09 November 2009

      Postby Dan Rathbun » Fri Mar 19, 2010 5:52 pm

      driven wrote: @Dan #!ruby warn_ovr.rb returns nil
      john

      @John..
      The first line is a boo-boo, should have taken out all of the unix-like load directive. (The file is not meant to run from the command line anyway. It was meant to be a 'require' script.)

      I'm rewriting that now as a Mix-In Module, rather than an override to module Kernel. (Backward compability issues, and so forth.) It would be 'forever' before we would hope to see any changes or additions to the Kernel module anyway, with all the other things they need to fix. (I had to laugh when I saw that Ruby 2.0 was due, or estimated to be complete 01/19/2038.)
      0
        I'm not here much anymore. But a PM will fire email notifications.
        User avatar
        Dan Rathbun 
        PluginStore Author
        PluginStore Author
         

        Re: WebDialogs - The Lost Manual — R1 09 November 2009

        Postby marksup » Mon Apr 25, 2011 3:47 pm

        I became alarmed at the significant differences in the appearance of my WebDialogs depending on the active browser (IE9, IE8, Chrome or Firefox) and so, based on the excellent advice above, added the following to my HTML...

        Code: Select all
        <!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN'
        'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
        <html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en'><head><meta http-equiv='X-UA-Compatible' content='IE=8; charset=iso-8859-1'/></head>


        This did wonders for the consistency, but as a direct result my <body scroll='no'> statement became ignored and a vertical scrollbar appeared. This was solved by using <body style='overflow-y:hidden'> instead.

        I also lost the use of 1.chr as the first space for textarea text - since 32.chr (the standard space) had always been ignored (except on a MAC!).

        Of more interest now... how to invalidate the maximise option (i.e. to keep the WebDialog panel at the original specified size) since max_width and max_height don't perform this function. Has anyone a suggestion?
        0

        marksup 
         

        SketchUcation One-Liner Adverts

        by Ad Machine » 5 minutes ago



        Ad Machine 
        Robot
         

        Next


         

        Return to Developers' Forum

        Who is online

        Users browsing this forum: No registered users and 8 guests

        Visit our sponsors: