Hi Frank,
You are right, using of the one-line control approach for a multiline
control is not correct.
By the way, isn't it possible to let GetTextRect() method preserve the
width and increase the height of the rectangle? In this case the
approximation step would not be necessary.
Thanks,
Mikhail.
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Mikhail,
It is a little bit different in case of big label with the comment. It
is multiline, so the new height should be calculated ( get the text
size, divide it to the current label width and multiply to the current
text height, retrieved using GetTextHeight() method ).
I don't think this is the right way, since breaking text doesn't really
scale this way. It might be a good first approximation to do it as
described above, but IMO it's not guaranteed to always succeed.
For a complete solution, I suggest to iteratively use the OutputDevice's
GetTextRect method. It allows to pass an input rectangle, and find out
which rect would actually be occupied by the given text. So, finding out
an "initial line count" with your algorithm should be followed by
verifying that in fact the text fits into the resulting rectangle. If it
doesn't, increase the line count until it does fit.
The disadvantage is that this method needs TEXT_DRAW_* flags, which need
to be the same as the ones passed by the control implementation to the
actual DrawText call. However, the GetTextRect's default value of
TEXT_DRAW_WORDBREAK is usually sufficient.
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
