I don't think using 8 e's or any fixed size for tab characters would
work as desired. In my case, the max value I got from trying to
find the px size was 557 but the actual width that was needed for
the list box was 1190 - almost twice the px size. If the size is not
calculated without the tab expansion, since a tab could represent
any amount based on the setTabulators values, a general average
may not be close to the actual. Also, I did try having the setWidthPx
statement immediately after the setFont statement, but I believe
the default windows font was still used. Since, in my case, the last tab
position is about 10 characters from what the right boundary would
ever be, through trial and error, I found that the 1190 worked for
my sample set. Now if I made it somewhat larger, like 1250, that
should suffice for any sample that this specific listbox would ever
have and should work okay for me. I also found that by expanding
the window size using the manual resize windows options, all of
the data could be seen even if I underestimated the actual value.
I can not for see any case where the size would go beyond the
screen width and thus not be seen even on a full screen.
Due to the above, I would not suggest you go to any effort at
all to attempt to include tabs in the calculation unless that
attempt would also include expansion of the tabs. Thanks again
for your help and explanation on how this works.
> On Sat, Jan 26, 2013 at 11:06 AM, Mark Miesfeld
> <miesfeld@...> wrote:
> 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.
> It turns out the API being used by ooDialog does not take into
> account tabs. However, there is another API that does. This is
> not available in ooDialog though, so it doesn't help you today.
> This second API can be given a list of the actual tab stop
> positions, which is probably what you would need for your list box
> usage. But, if it is not given the list, it simply calculates a
> tab's width as 8 times the average width of a character.
> So, my suggestion to calculate the width of 'eeeeeeee' separately
> and add that width times the number of tabs you have in your string
> to the initial width you get from getTextSizePx() should give you a
> pretty accurate width.
> At some point if I run out of things to do, I may add a
> getTabbedTextSize() method.
> Mark Miesfeld
Art Heimsoth - artstore@...