Sketchup.parse_length
-
Is this a known bug?
I had assumed that
Sketchup.parse_length(X)
doesn't accept badly formed length strings..But you can give it any old crap and it gives back a value (looks like its the metric-to-inches multiplier it uses).
` Sketchup.parse_length("1.0cm")
=> 0.393700787401575Sketchup.parse_length("1.0splishysplash")
=> 39.3700787401575`If I have to write a Regex to parse the string to check it valid before giving it to parse_length(), then I might as well do the last step of conversion myself.
Kinda brain-damaged...
Adam
-
I had thought that
Sketchup.parse_length
was the same asString.to_l
- but after having another look at it...` '10cm'.to_l
3.93700787401575'10foobar'.to_l
Error: #<ArgumentError: (eval):155:in `to_l': Cannot convert "10foobar" to Length>
(eval):155
(eval):155Sketchup.parse_length( '10cm' )
3.93700787401575Sketchup.parse_length( '10foobar' )
nilSketchup.parse_length( '10.0foobar' )
nilSketchup.parse_length("1.0splishysplash")
nil`Seems that
Sketchup.parse_length
doesn't raise any errors. But on the other hand, I getnil
on invalid strings...@adamb said:
If I have to write a Regex to parse the string to check it valid before giving it to parse_length(), then I might as well do the last step of conversion myself.
You could, but you'd also have to deal with the user's locale for decimal symbol...
-
Speaking of locale...
` Sketchup.parse_length("1,0splishysplash")
0.0393700787401575"1,0splishysplash".to_l
0.0393700787401575"1,0".to_l
0.0393700787401575`I'm using Norwegian locale - now I see the result you got. Whenever it fails to extract a unit identifier in the string it appear to assume the number it find is in the model units. This might be "by design" ... ?
-
@adamb said:
AdamB wrote:
If I have to write a Regex to parse the string to check it valid before giving it to parse_length(), then I might as well do the last step of conversion myself.You could, but you'd also have to deal with the user's locale for decimal symbol...
Absolutely! Really don't want to re-invent the wheel.
BUT.. you're getting different results to me. I don't get nil back, I get 39.3700787401575 back - which really screws stuff up.
(I've always checked for nil).I feel a witch hunt coming on.. it is almost Halloween..
Ah, just saw your new post! If it is "by design", thats an extremely poor decision.
-
Playing some more, I think its a straight bug in Sketchup code. As in, without a decimal separator the behaviour is as expected..
Ultimately, I can't rely on it so I'll need to parse everything myself.. grrr..
Adam
-
@adamb said:
Absolutely! Really don't want to re-invent the wheel.
While there is a method to parse lengths based on the user's current locale. There is no way to parse floats. Or coordinates (like you can do with the Move tool, specifying absolute or relative coords...)
-
This is what I'm using in LightUp
/([0-9]+[\,\.]*[0-9]*)([\w\"\']+)?$/
-
@adamb said:
This is what I'm using in LightUp
/([0-9]+[\,\.]*[0-9]*)([\w\"\']+)?$/
Yea, I'm using something similar. I think that when one assume that the decimal is either period or comma one cover pretty much everything. I've not heard of anyone using anything else. It's worse with the list separator. At the moment I assume that if one use comma for decimal that semi-colon is the list separator. ...though I'm less sure of this one...
-
If this can help, I have coded methods to parse lengths (as well as integers and floats) with or without formulas.
For the locale, I decided to accept both the dot and comma as decimal separators, so that there is no interference with the local settings.You can get some inspiration by browsing the file Lib6Traductor.rb in LIBFREDO6_Dir_xx folder. Just search for methods like:
**** Traductor.string_to_length(s)- Traductor.string_to_length_formula(s)
- Traductor.string_to_float(s)
- Traductor.string_to_float_formula(s)***
Fredo
-
Somebody recently did alot of this work...
ParseArthimetic
rings a bell (DING!) -
@unknownuser said:
If this can help, I have coded methods to parse lengths (as well as integers and floats) with or without formulas.
For the locale, I decided to accept both the dot and comma as decimal separators, so that there is no interference with the local settings.You can get some inspiration by browsing the file Lib6Traductor.rb in LIBFREDO6_Dir_xx folder. Just search for methods like:
**** Traductor.string_to_length(s)- Traductor.string_to_length_formula(s)
- Traductor.string_to_float(s)
- Traductor.string_to_float_formula(s)***
Fredo
Nice work Fredo.
However, in your string_to_length(), I don't think SketchUp supports units of "km", "feet" and "mile" (though it will accept ' and " for foot and inch respectively)
What's so frustrating about stuff like this is not that software has bugs - it all does - just that for the rest of time you have to have scripts that jump through hoops to side-step this, duck to avoid that, jump to miss that... making them a right ol mess.
I guess there is an argument here that based on version number, you do go in and overload the core Sketchup methods to fix them. Problem is that while there are a bunch of great coders that I would totally trust to do this well, there's a lot more that don't have the experience to do this right, so it would be opening a horrible can of worms. I'm looking at you, Matchbox.
Adam
-
@adamb said:
However, in your string_to_length(), I don't think SketchUp supports units of "km", "feet" and "mile" (though it will accept ' and " for foot and inch respectively)
These functions are primarily geared at getting input from user (via VCB or dialog box). So, even if units are not supported by SU, the notation accepts it (like the dot and comma for the decimal separator).
The functions also support the architectural notation with ' and " (though I am not fully familiar with it). For instance
s = "2'3\" + 5' 8\"" --> 2'3" + 5' 8" Traductor.string_to_length_formula(s) --> 95.0 s = "3\" * 4" --> 3" * 4 Traductor.string_to_length_formula(s) --> 12.0 Traductor.string_to_length("1.0splishysplash") --> nil
Fredo
Advertisement