WebDialogs - The Lost Manual — R1 09 November 2009

Jernej Vidmar

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.

thomthom

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


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


function decode(base64str)
  eval(decode64(base64str));
end

DIEGO-RODRIGUEZ

interesting applications for html

html 5
http://html5demos.com/

and

http://www.dhtmlgoodies.com/index.html?page=dhtml-suite

thomthom

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.

tbleicher

@thomthom said:

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

thomthom

@tbleicher said:

@thomthom said:

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

Jim

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

thomthom

@jim said:

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.

Pout

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

chrisglasier

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

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

Jim

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

$VERBOSE

and

$DEBUG

and

$-w

thomthom

@jim said:

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

$VERBOSE

and

$DEBUG

and

$-w


> $VERBOSE
false
> $DEBUG
false
> $-w
false

SU 7.1.6859
OSX 10.4

Dan Rathbun

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

chrisglasier

@mmyoung said:

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.

driven

@chrisglasier said:

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

Jim

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.

Dan Rathbun

@driven said:

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

Dan Rathbun

@jim said:

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

**$DEBUG**
The 'Pick-Axe' book says falseis the default.

@jim said:

**$VERBOSE** [alias] **$-w**
The 'Pick-Axe' book says falseis 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" )
%(#008B8B)[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 ###


# 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?

marksup

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

<!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?

thomthom

@marksup said:

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?

By setting the resize argument of WebDialog.new.