While pixel peeping with the columns of a browse I found that (at least in 11.2) in my browse, the column width is not what Progress reports.
Look at this example:
The fill-ins are filled like this:
fill-in-1 = {&browse-name}:GET-BROWSE-COLUMN(1):WIDTH-PIXELS.
fill-in-2 = {&browse-name}:GET-BROWSE-COLUMN(2):WIDTH-PIXELS.
fill-in-3 = {&browse-name}:GET-BROWSE-COLUMN(3):WIDTH-PIXELS.
fill-in-4 = {&browse-name}:WIDTH-PIXELS.
If I measure the column width using a program like Paint.net or Greenshot, it appears that the columns are 4 to 5 pixels wider than what Progress reports. The width of the browse itself matches. There I find the following widths:
Has anyone noticed this before and is it consistent across different versions?
Has the browse got fit last column active? I've found that sometimes messes with column widths.
The code which handles WIDTH-PIXELS for browse columns subtracts 4 from the width to account for the column separators. It seems like it's double counting the separators since they're 2 pixels wide. It has done this since 9.0A.
@James: fit-last-column does not make a difference.
@Matt: thanks for clarification. Could it be that the separators were wider in older versions?
The separators have been 2 pixels wide as far back as I can easily look in the history, which is 9.1A. This is the offending line of code. It's double counting them on purpose. I don't see the reason for doing that and the comments and bug history don't provide any clues.
data->f.calc.intval = pc->w - (2 * WW_BROWSE_HSEP);
When you turn-off the vertical scrollbar... is it the same... or what Matt mentions... or...?
Vertical scrollbar makes no difference, other than that you need to take into account that it takes up 16 pixels of the available width within the browse. Funny part is, that if you walk the columns of the browse and add up their widths, it does not match with the browse width. That's where I noticed the problem. I was working on resizing logic that would resize only the character columns in the browse.
I was planning to use a factor that would be calculated in the window resized trigger, then calculating the amount of space all character columns used and resizing just those columns, but my columns were too wide and I kept thinking that my resize logic was wrong.
Even keeping in mind that columns are actually wider than reported didn't make it easier. You have to keep in mind to add 4 when you read the value and to subtract 4 when you set it, so I ended up with distributing pixels evenly accross the character columns. If you make the window (and browse) 100px wider and you have 4 character columns, each will get 25px extra.
By the way, according to Matt, the separators are 2px wide, but my drawing program says 1px. If I look at a zoomed in portion of the screen I see this:
The cell with value "35,1" should be reported as 27px wide (or, arguably, 28 if you include the separator). Then you could at lease add up all widths and find the same width as that of the browse as a whole. As you can see the scrollbar is 16px wide (15px gray and 1px light gray)