Return values

PaulG

Thanks Dan, although .to_mm.to_mm.to_mm looks like some kind of comedy code. I gotta say Ruby seems the most obscure, non-sensical language I have used so far.

thomthom

@dan rathbun said:

You must convert back mm, using .to_mm, but because you cubed it, you have to "cube" the conversion

It's better to use .to_l - then when that Length instance is outputted as string it's printed in the user's units.
As for area - use Sketchup.format_area

Unfortunately there is no method for volume - they left that one out. So in that particular instance you need to write the conversion from cubed inches to user units yourself.

thomthom

prompts = ["Width mm", "Breadth mm", "Height mm"] defaults = ["100", "100", "100"]

Let SketchUp handle the units for you. If you feed the input box Length objects as defaults - it converts the user input to Length's for you.
defaults = [100.mm, 100.mm, 100.mm]

It's better to work with units in SketchUp's units - internally inches - and always ensure you have Length objects when you output to the user. That way the user gets the units in his/her preferred unit and you don't have to do a thing.

Dan Rathbun

There was another topic on this issue, I think I may have posted a method in there.
Or.. hmmm... It may have a "[Code]" prefix in the title.
ADD: found it: Volume of Multiple Groups
You might get some ideas from that, and there is a link to one of TIG's old utilities.

Anyway.. TT... One thing you or TIG have not done yet is a "Units: The Lost Manual"

thomthom

@dan rathbun said:

Anyway.. TT... One thing you or TIG have not done yet is a "Units: The Lost Manual"

That is in fact on my list to write up.

Dan Rathbun

@paulg said:

Thanks Dan, although .to_mm.to_mm.to_mm looks like some kind of comedy code. I gotta say Ruby seems the most obscure, non-sensical language I have used so far.

Of course it does. It's not Ruby's fault, that is not Ruby best practice.

There are many "missing" methods in various API classes.

In fact what we are missing here, are Area and Volume classes. When you multiply 2 Length instance objects, they get converted to Float.. and then you cannot tell what the math ops were to end up with the value.

In other words... math on a Length object, by any other Numeric subclass, should return a new Length object. (Like adding the frontage of building lots along a right-of-way, or math ops with wall lengths to arrive at a perimeter length.)

Multiplying two Length objects, should return a new Area object.

Multiplying 3 Length objects, OR an Area object by a Length object, should return a new Volume object.

However, multiplying Area objects, by other non-length Numeric objects, should result in a new larger Area object.

.. etc.

Problem is, current version of SketchUp would not know how to handle these new classes.

thomthom

@dan rathbun said:

Anyway.. TT... One thing you or TIG have not done yet is a "Units: The Lost Manual"

http://www.thomthom.net/thoughts/2012/08/dealing-with-units-in-sketchup/

Dan Rathbun

NO faults that I can see, after a quick read.

thomthom

@dan rathbun said:

:thumb:

NO faults that I can see, after a quick read.

I'm sure there's some input to be made on the library I posted at GitHub - linked at the bottom. I'd collected it from various helper methods from different plugins of mine. The volume and area functions was originally not in separate classes - but I liked idea idea of Area and Volume as separate classes.

Dan Rathbun

@thomthom said:

@dan rathbun said:

... but I liked idea idea of Area and Volume as separate classes.

I also ! (as I said above.)

And the API needs these, and the app needs to use them.

thomthom

And locale handling for Floats.

thomthom

@dan rathbun said:

And the API needs these, and the app needs to use them.

Yes - agree. Your idea about multiply two Length to get and Area, and Area with Length to get a Volume is very elegant. I'd very much like to see this into SU9.