WebDialog parameters passed to callback cause .to_l error

sdmitch · 18 Nov 2014, 17:24

While playing around with a WebDialog, I found two puzzling things. First, an input text box with " 0, 0, 0" in it is changed to "+0,+0,+0" in the parameters passed to a callback function. Second, if you split that string into x,y,z and attempt to convert to a length, you get an error.

pt1=+0,+0,+0
Error: #<ArgumentError: Cannot convert "+0" to Length>
C:/Users/Public/SketchUp/Plugins/davesexcel.rb:42:in to_l' C:/Users/Public/SketchUp/Plugins/davesexcel.rb:42:in block (2 levels) in show_dialog'
C:/Users/Public/SketchUp/Plugins/davesexcel.rb:38:in each' C:/Users/Public/SketchUp/Plugins/davesexcel.rb:38:in block in show_dialog'
-e:1:in `call'

jolran · 18 Nov 2014, 18:18

How bout .to_f.to_l ?

Jim · 18 Nov 2014, 18:40

How are you passing the values to the Ruby code?

sdmitch · 18 Nov 2014, 18:50

@jim said:

How are you passing the values to the Ruby code?

Yes, .to_f.to_l works but why should that be necessary. ' 0'.to_l and '-0'.to_l work. Why not '+0'?

Through a form action and "Submit" button.

Jim · 18 Nov 2014, 18:54

What I mean is, are you encoding the string before passing it to Ruby? How, specifically? Have you inspected the string before passing it to Ruby? It looks like the spaces are being encoded to plus signs, which is not an uncommon way to encode web data.

sdmitch · 18 Nov 2014, 18:58

@jim said:

What I mean is, are you encoding the string before passing it to Ruby? How, specifically? Have you inspected the string before passing it to Ruby? It looks like the spaces are being encoded to plus signs, which is not an uncommon way to encode web data.

The data is typed into a <input type='text'> box. Any encoding would have to be done when the parameters are passed to the callback function.

Jim · 18 Nov 2014, 19:07

How? Are you passing it as a single string?

What I have done in the past is split values on the JavaScript side, trim leading and trailing whitespace, then join the values together using '|' character. Commas do not make good value separators because some languages use commas where we would use a decimal point in a number. Then pass the string to Ruby and split the values on the '|'.

sdmitch · 18 Nov 2014, 19:15

@jim said:

How? Are you passing it as a single string?

What I have done in the past is split values on the JavaScript side, trim leading and trailing whitespace, then join the values together using '|' character. Commas do not make good value separators because some languages use commas where we would use a decimal point in a number. Then pass the string to Ruby and split the values on the '|'.

Yes, as a single string. It's no big thing, I just thought it was curious.

def webdialogtest
	dlg = UI;;WebDialog.new("DialogTest", false,"DialogTest", 600, 150, 150, 150, true);
	html = <<-HTML
	<html>
		<body>
			<form action="skp;CallBack@">
				<input name="pt1" type="text" style="width; 60px" value="" />
				<input type="submit" value="submit">
			</form>
		</body>
	</html>
	HTML
	dlg.set_html html
	dlg.show
	dlg.add_action_callback("CallBack") {|dialog, params|
		puts "You called CallBack with; " + params.to_s
		var,val = params.split("=")
		x,y,z=val.split(",")
		pt=Geom;;Point3d.new(x.to_l,y.to_l,z.to_l)
		puts pt
	}
end
webdialogtest

Jim · 18 Nov 2014, 22:56

It is curious, and there is a lot going on behind the scenes. This document explains some of what is going on.

You are relying on the WebDialog (and HTML specifications) to put together your form data. The form data is sent to the Ruby script as one string. There is a limit to the length the string may be. The browser replaces spaces with + signs and and possibly other substitutions . Form data is appended to the string in order they appear in the form with a & and a name/value pair separated by =.

The problems start if you need to pass any of the symbols +, space, &, or = from the web dialog form to your Ruby script. You will find the form data difficult if not impossible to parse on the Ruby side. Here is a contrived example:

Because of these limitations, most folks have adopted some alternative method of data serialization to encode the form data such as JSON or Base 64 encoding, all of which require some use of JavaScript to process the form data prior to sending it to the Ruby script.

Jim · 18 Nov 2014, 23:12

@jolran said:

How bout .to_f.to_l ?

Careful..

"1".to_l ==> 1.000000cm

"1".to_f.to_l ==> 2.540000cm

jolran · 18 Nov 2014, 23:42

Yes, that is a side effect. If one would take that approach...

It may be worth to mention "1.0".to_l doesent work either..

I think it's debatable using forms at all..
Passing onclick events to functions gives more options parsing the strings before sending them to Ruby..

driven · 18 Nov 2014, 23:49

@jim said:

...Commas do not make good value separators because some languages use commas where we would use a decimal point in a number...

can something like this be used to find the digit separator

      [1.1].length == 2 ? sep = "." ; sep = ","
      x,y,z = val.split(sep)

I also found if you use to_f to clean any non digit's up on the ruby side, you break to_l

i.e my input of 1 will become 25.4mm...

john

driven · 18 Nov 2014, 23:53

@jolran said:

It may be worth to mention "1.0".to_l doesent work either..

"1.0".to_l 
=> 1.0mm

"1.0".to_f.to_l 
=>25.4mm

I missed a couple of post...

jolran · 19 Nov 2014, 00:00

Ah yeah, Jim said that already.. I only looked at the code

puts "1.0".to_l still don't work for me.
Error: #<ArgumentError: (eval):258:in `to_l': Cannot convert "1.0" to Length>

driven · 19 Nov 2014, 00:04

@jolran
are you still on v8...

jolran · 19 Nov 2014, 00:11

Yes John. Still on 8. I havent had time to test the new good stuff..

Btw .to_s.gsub(".", ",").to_l worked for me in the node editor. But I can't remember if I did an eval on a hash_String before running that..
I havent touched the JS for a while...

Now seeing this I wonder if I got it all wrong, it seemed to work properly

edit: puts "1.0".to_l don't work(for me) on 2014 either. But it never has so I'm suprised you made it work. Maybe because your on Mac ?

Oh yeah and even how ugly it may look this works: eval("+1.0").to_s.gsub(".", ",").to_l
Then again I believe TS is not interested in hacks..

Jim · 19 Nov 2014, 08:04

@jolran said:

edit: puts "1.0".to_l don't work(for me) on 2014 either. But it never has so I'm suprised you made it work.

Really? Does "1,0".to_l work?

jolran · 19 Nov 2014, 08:22

@unknownuser said:

Really? Does "1,0".to_l work?

Yes.

Jim · 19 Nov 2014, 09:28

A begin..rescue clause can be used to test this. For a one-off:


len = begin
  "1,2".to_l
rescue
  "1.2".to_l
end

p len

But obviously it would be better to write a method to handle this for more cases.

jolran · 19 Nov 2014, 10:38

heh yeah that works to.

Don't know if it's prettier than a gsub, but if it works..

Does the code pass through transparently if no errors, or does this add overhead?

It might be interesting to do a speed comparing against gsub variant.

@unknownuser said:

But obviously it would be better to write a method to handle this for more cases.

Yeah, but sometimes one run into corners where direct evaluation is necissary.
Like get_element_value at some odd place where not possible to go through normal routine.