[Mark Miesfeld <miesfeld@gm...>]

On Sat, Jan 26, 2013 at 10:38 AM, Art Heimsoth <artstore@...>wrote:

> Is there more to determining the pixel size of the text string?  In using
> your example, the largest pixel string value was 557, and varied from
> 224 to 557, yet the text strings being added to the listbox fill the
> horizontal width of the box.  It is a formatted content, and tab characters
> are used to position each column of data.


You are correct, if you have tabs in there, the actual width of the string
will not be correct.  The operating system API being used does nothing
special for tabs.  I think, I'm not sure.  Maybe it does, see below.  The
wrong font is surely a problem, maybe fixing that will be sufficient.



>  The font being used is
> Courier New with a pitch of 10 - I suspect that the getTextSizePx is
> sizing the string before Tab expansion and assumes the default font for the
> dialog, which with tabs and different pitch characters would make quite
> a difference.


This is also correct.  The way I coded it, assumed the font be the dialog
font for getTextSizePx().  However the method is a WindowsBase method.
 Which means it is a method for *all* windows.  A list box is a window.

It should work better, if you assign the font to the list box first, then
invoke the method on the list box object instead of on the dialog object.

The operating system does not provide a way to get the display width of a
tab character that I know of.

The first thing I would try would be to get the text size using the list
box object.  This may be correct, if the Windows API being used does
calculate the tab width properly.

Then, if that is way off and it is obvious the actual tab width is not
factored in, then I would get the width of 8 'e's, count the tabs in your
string and add count * 'eeeeeeee' width.  Maybe 7 'e's instead of 8.  I'm
sure the operating system assigns some width to the tab character.

If nothing else, just double the calculated width and you should be okay.
 If not triple it.  ;-)  The only down side that I know of for having it
too wide is that the list box probably uses more memory
than absolutely necessary.  This was a big deal in 16-bit Windows.  Today,
with modern hardware, it is probably a trivial consideration.

--
Mark Miesfeld