width/height of Text are only filled after drawing

I've noticed an odd behavior with the Text Drawable: the width and height properties are not populated during initialize() or when updating the text with setText(). Instead, they’re only set after draw() is called. This means that initially, width and height will be zero, and if you change the text after drawing, width still reflects the previous value. I suspect the same issue applies to height when calling setFont() with a different font, although I haven't tested that.

This behavior contrasts with Bitmap or TextArea, where width and height are always available and reflect the current state. I understand this might be because Garmin decided to allow text width calculations only using a Dc, but it still feels inconsistent and makes layout logic unnecessarily complex. As a workaround, I’m creating a 1-pixel BufferedBitmap and using its Dc to calculate text dimensions manually. It works, but it’s a bit of a hack.

Do you think this warrants a bug report, or is it more of a design quirk we just have to live with?

0 flocsy🤠 5 months ago

Maybe you should show us a bit more. Where does the Drawable come from? xml? Monkey C code?, where do you want to access it's dimensions, etc...

0 the-ninth 5 months ago in reply to flocsy🤠

It’s coming from Monkey C code, and I’d expect width to be available after initializing it with :text and :font.

var textDrawable = new Text( {
    :text => "Hello World",
    :font => Graphics.FONT_MEDIUM,
    :color => Graphics.COLOR_WHITE
    :backgroundColor => Graphics.COLOR_BLACK
} );

// from here on, I'd like to access textDrawable.width and get the width of the text with the given font

0 flocsy🤠 5 months ago in reply to the-ninth

I haven't used Text, so correct me if I'm wrong. If you have a long sentence as text, and you draw the same Text object into different "places", is it possible to get different results? For example:

in wide space:

Long sentence that might not fit one line.

in narrow space:

Long sentence that might
not fit one line.

0 the-ninth 5 months ago in reply to flocsy🤠

No, that's a TextArea. A TextArea has a defined width and height, and accepts one or more fonts. It automatically inserts line breaks and selects the most suitable font to make the text fit.

A Text, on the other hand, is more like Dc.drawText. It simply draws the text at a specified position using a given font size. The width and height aren't provided by the calling code—they should be determined by the class itself, similar to how it works with a Bitmap Drawable.

0 flocsy🤠 5 months ago in reply to the-ninth

so maybe you can use dc.getTextDimensions()? It won't be exactly the widht and height of the Text I guess, but it might be close enough?

0 jim_m_58 5 months ago in reply to flocsy🤠

dc.getTextWithInPixels("How Wide?",Graphics.FONT_MEDIUM)

returns the width of the string using the specified font. I use it all the time for spacing with no problem.

If I have a long string, I even use it to split it into multiple lines so it displays ok. Did this before TextArea was even introduced in 3.1.0 and still do it today.

Here's a case where I get the forecast back as a long string and split it up for display:

0 the-ninth 5 months ago in reply to flocsy🤠

flocsy🤠 said:
so maybe you can use dc.getTextDimensions()? It won't be exactly the widht and height of the Text I guess, but it might be close enough?

I believe that does give you the exact dimensions—so yes, it works, as does getTextWidthInPixels.

But what if you don’t have a Dc yet and need to perform layut calculations?

I’m aware that with a Dc, you can compute the text width directly. And even without one, there’s a workaround—as I mentioned in my original post:

“As a workaround, I’m creating a 1-pixel BufferedBitmap and using its Dc to manually calculate text dimensions. It works, but it’s a bit of a hack.”

So just to clarify: this post isn’t about looking for a workaround or solution—I already have one. My point is that I find the behavior of Text inconsistent compared to other Drawable elements, and that inconsistency is what I’m highlighting here.

0 flocsy🤠 5 months ago in reply to the-ninth

You won't be able to do any calculations without Dc. In theory it should be possible to know the font and calculate with it only, bit I don't think it's possible with the apis we have available

0 the-ninth 5 months ago in reply to flocsy🤠

flocsy🤠 said:
You won't be able to do any calculations without Dc. In theory it should be possible to know the font and calculate with it only, bit I don't think it's possible with the apis we have available

To me, placing getTextWidthInPixels in Dc and getFontHeight in Graphics feels like an arbitrary decision. And yes, that arbitrary choice is likely why Text behaves the way it does. But I still find it problematic — it's inconsistent with other Drawable elements, undocumented, and makes life harder for users.