why would text.contentHeight differ from text.height?

Other
#1

Hi,

I’m doing:

  tdummy = display.newText (“Edit”, 100, 100, native.systemFont, 40)

 

    print (tdummy.contentHeight, tdummy.height)

 

and am seeing tdummy.contentHeight is 48, and tdummy.height is 48.009376525879

 

 

…and am wondering why the difference!

 

thanks,

 

Stan (still desperately wanting a modern Lua in Corona) Sieler

#2

It’s explained in the documentation: http://docs.coronalabs.com/api/type/DisplayObject/contentHeight.html

“This is similar to object.height except that its value is affected by y scaling and rotation.”

Rob

#3

thanks. 

I wish the documentation made it clear which value corresponded to the values one would provide back to Corona via some API call.  

I.e., if I’m trying to create some object of the same on-screen/visible height, do I get the info from .height or .contentHeight?  Since the values differ, the answer is clearly one or the other (or, possibly, “neither, use <somethingelse>” :slight_smile:

The entire question arose because a prior post (someone else) asked about determining the size of a widget.newButton,

and the answer was to use .height or .contentHeight of a temporary text object with the same font size  …  had such buttons

possessed the same x/y/height attributes as display objects, the question wouldn’t have arisen, I suspect.

thanks.

Stan

#4

Best Practice: I use obj.contentHeight and obj.contentWidth almost exclusively.

#5

widget.newButton()s are not directly display objects. They are an object that contains a display.newGroup that holds a display.newRect and some other display objects. I don’t believe that widget.newButton has a direct .height or .width property 

In most cases, I think .height and .contentHeight are going to be the same or very close unless you’ve been scaling or rotating the object. I would personally use .height in most cases.

Rob

#6

Thanks, Rob.

I figured something like that (nested stuff), but decided against looking inside one to get to the nested objects … not enough reason to get dirty like that for this minor problem.

I’m currently using the min of the two, rounded to an integer value.

thanks again,

Stan (sure wish we had modern Lua with “//” integer division) Sieler

#7

@roaminggamer thanks … given the one you suggest is an integer (in my test case), it seems reasonable to think it’s closer to the pixel values I want.

SS

#8

It’s explained in the documentation: http://docs.coronalabs.com/api/type/DisplayObject/contentHeight.html

“This is similar to object.height except that its value is affected by y scaling and rotation.”

Rob

#9

thanks. 

I wish the documentation made it clear which value corresponded to the values one would provide back to Corona via some API call.  

I.e., if I’m trying to create some object of the same on-screen/visible height, do I get the info from .height or .contentHeight?  Since the values differ, the answer is clearly one or the other (or, possibly, “neither, use <somethingelse>” :slight_smile:

The entire question arose because a prior post (someone else) asked about determining the size of a widget.newButton,

and the answer was to use .height or .contentHeight of a temporary text object with the same font size  …  had such buttons

possessed the same x/y/height attributes as display objects, the question wouldn’t have arisen, I suspect.

thanks.

Stan

#10

Best Practice: I use obj.contentHeight and obj.contentWidth almost exclusively.

#11

widget.newButton()s are not directly display objects. They are an object that contains a display.newGroup that holds a display.newRect and some other display objects. I don’t believe that widget.newButton has a direct .height or .width property 

In most cases, I think .height and .contentHeight are going to be the same or very close unless you’ve been scaling or rotating the object. I would personally use .height in most cases.

Rob

#12

Thanks, Rob.

I figured something like that (nested stuff), but decided against looking inside one to get to the nested objects … not enough reason to get dirty like that for this minor problem.

I’m currently using the min of the two, rounded to an integer value.

thanks again,

Stan (sure wish we had modern Lua with “//” integer division) Sieler

#13

@roaminggamer thanks … given the one you suggest is an integer (in my test case), it seems reasonable to think it’s closer to the pixel values I want.

SS