On Sat, Jan 26, 2013 at 10:38 AM, Art Heimsoth <artstore@artheimsoth.com> 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