WebDialog parameters passed to callback cause .to_l error
-
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:into_l' C:/Users/Public/SketchUp/Plugins/davesexcel.rb:42:in
block (2 levels) in show_dialog'
C:/Users/Public/SketchUp/Plugins/davesexcel.rb:38:ineach' C:/Users/Public/SketchUp/Plugins/davesexcel.rb:38:in
block in show_dialog'
-e:1:in `call' -
How bout .to_f.to_l ?
-
How are you passing the values to the Ruby code?
-
@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.
-
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.
-
@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.
-
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 '|'.
-
@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
-
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.
-
-
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.. -
@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
-
@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...
-
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> -
@jolran
are you still on v8... -
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.. -
@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? -
-
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.
-
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.
Advertisement