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 > <miesf...@gmail.com> wrote: > > On Sat, Jan 26, 2013 at 10:38 AM, Art Heimsoth > <artst...@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. >> > > 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 - artst...@artheimsoth.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Oorexx-users mailing list Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
