WebDialog parameters passed to callback cause .to_l error

driven

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

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

@jolran
are you still on v8...

jolran

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

@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

@unknownuser said:

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

Yes.

Jim

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

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.

jiminy-billy-bob

I use this :

<span class="syntaxdefault"><br />def self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">decimal_separator<br />        </span><span class="syntaxstring">'1.0'</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l<br />        return </span><span class="syntaxstring">'.'<br /></span><span class="syntaxdefault">    rescue ArgumentError<br />        return </span><span class="syntaxstring">','<br /></span><span class="syntaxdefault">end</span><span class="syntaxcomment">#def<br /><br /></span><span class="syntaxdefault">def self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">str</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    return str</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_s</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">gsub</span><span class="syntaxkeyword">(/\</span><span class="syntaxdefault">s</span><span class="syntaxkeyword">+/,</span><span class="syntaxstring">''</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">gsub</span><span class="syntaxkeyword">(/(\.|,)/,</span><span class="syntaxdefault"> self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">decimal_separator</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">to_l<br />end</span><span class="syntaxcomment">#def<br />&nbsp;</span><span class="syntaxdefault"></span>

This allows me to handle pretty much anything the users enters.

driven

isn't it faster to test for true


def self.decimal_separator
    [1.1].length ==  2  ?  ',' | '.'
end#def

john

jolran

Guys

This place is a great source of information.

jiminy-billy-bob

@driven said:

isn't it faster to test for true

Maybe It's widely fast enough for my use (Parsing one string at a time entered by the user)

tt_su

@driven said:

isn't it faster to test for true


> def self.decimal_separator
>     [1.1].length ==  2  ?  ',' | '.'
> end#def

john

You never know for sure until you profile the code. And in Ruby you get many surprises. That being said - unless you have a noticeable performance issue there is little need to pre-optimize.

Jim

@driven said:

isn't it faster to test for true


> def self.decimal_separator
>     [1.1].length ==  2  ?  ',' | '.'
> end#def

john

Maybe I do not know off-hand. This is code you would run at most one time in a plugin to determine which separator to use so it isn't terribly important to optimize.

The code that actually performs the conversion may need optimized especially if there are many conversions to do.

Jim

Had this idea today:


separator = (1/Float(2)).to_s[1]

driven

even shorter

separator = Float(1).to_s[1]

TIG

But that Ruby float as a string is ALWAYS going to return "1.0", so it always sets as "." even when the user's day-to-day decimal-separator is ","
The issue is how the user input of "1,0" is correctly read as a float or a length.
In the UI 'input' the default input type pretty much sorts that out.
Since 1.0.m displays as 1.000m or 1,000m depending on the user's locale [and of course the model's unit settings]
In a webdialog it's more awkward, because all input is a string that needs 'interpreting'.
So the earlier posts' trickery using lengths etc to get the real separator would help...
Certainly when initially populating the webdialog with decimal values...
Like sep = (begin;'1.0'.to_l;'.';rescue;',';end)
So if sep==',' we present decimal numbers differently using something like tr('.',',')?
But surely some leeway could be used...
What if a user first inputs x = 1.0 then x = 2,3 ?
Should BOTH be acceptable ?
So assuming they are expected as floats...
if sep=='.' x.tr!(',','.') else #',' x.tr!('.',',') end
For the display-side this makes either typed in separator suit the the 'locale', but on the Ruby-side, it's always x_float = x.tr(',','.').to_f
For inputted 'lengths' it is different, because the Ruby-side expects it to be in the locale separator format...
The first sep==...tr... still applies to ensure it's locale friendly... BUT then the x_length = x.to_l must be used Ruby-side...