Return values

PaulG

Hello,

I am confused with the output from the volume method it is called with puts(box.volume)and the output is 61.023... I am expecting it to be 100x100x100. The three test puts() in the get_data method show the correct value and the box created in the draw_box method has the correct dimensions.


Sketchup.require 'sketchup.rb'

module  MyModule
	class Box
		def volume
			return(@width * @breadth * @height)
		end
		
		def initialize
			@width = nil
			@breadth = nil
			@height = nil
			main()
		end
		
		def main
			get_data()
			draw_box()
		end
		
		def get_data
			prompts = ["Width mm", "Breadth mm", "Height mm"]
			defaults = ["100", "100", "100"]
			results = UI.inputbox(prompts, defaults, "Box Values")
			
			@width = results[0].to_i.mm
			@breadth = results[1].to_i.mm
			@height = results[2].to_i.mm
			
			puts(@width)     #this outputs expected value
			puts(@breadth)   #this outputs expected value
			puts(@height)    #this outputs expected value
		end
		
		def draw_box
			model     = Sketchup.active_model
			entities  = model.active_entities
			
			pt1 = [0,0,0]
			pt2 = [0,@width,0]
			pt3 = [@breadth,@width,0]
			pt4 = [@breadth,0,0]
			
			face = entities.add_face(pt1,pt2,pt3,pt4)
			face.reverse!
			face.pushpull(@height)
		end
	end
end

Dan Rathbun

100.mm becomes a Length class (which is inches.)

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

"%fmm#{179.chr}" % (@width * @breadth * @height).to_mm.to_mm.to_mm

see Kernel.sprintf() for info on format strings

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"

Dealing with Units in SketchUp

There are extensions to the base classes in SketchUp’s Ruby API which often new SketchUp plugin developers overlook. If you aren’t aware of them you might find yourself reinventing many…

Procrastinators Revolt! (www.thomthom.net)

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.