It looks correct on my side and as you have the same default column width than one of my tests computer …
The 'scientist' way just follows in fact a logic at child level : from the paper size minus the margins,
how many rows and how many columns blocks can fit a print page
which seems so easy with any smart application but Excel is not one of that kind !
The first 'issue' is the paper size as Excel has no height & width for the page setup but just a code !
For example for an A4 paper size the page setup code is 9 …
Ok, according to this code it's not difficult to evaluate a width according to the page setup orientation.
And for the usable width it just needs to substract the margins.
But Excel does not work internally with centimeter or inch but use a pair of units !
Points for the Width property and a 'character' unit for the ColumnWidth property, so weird ! …
A partial reason comes from this observation under Windows : a worksheet has a 8.43 default column width on a computer
but on another computer opening the same workbook the same worksheet has a 8.11 default column width !
That comes from the Windows screen display setup, the dpi (dots per inches) in order Excel can handle pixels
like when you manually enlarge a column you can see the Character width like 8.43 and the (pixels) …
Excel has the necessary functions to convert a page width in Centimeters or Inches to Points.
The centimeters converted to points have the same value on both computers but does not match
the true usable width in the worksheet which is different between computers 'cause of the dpi setup :
the reason why my first demonstration takes an empirical path to evaluate the usable width
- the same way even an Excel beginner can operate manually - and
approximates the blank column width which may not be optimal in some cases …
So warming a couple of neurons, the idea is to apply a 'scientist' logic when possible
and an empirical way only when there is no other choice : a mixed way to maximise the blank column width …
And, as playing with column width consumes time during the execution
the child logic says to save the results rather than calculating at each launch the same results, too obvious !
So once the source page setup is fixed like the source columns range width, the first time the Mixed procedure
is launched it will take time to evaluate the necessary values (usable width, columns blocks #, blank column width)
but the next run, even if Excel was closed or the computer was rebooted, for the same source worksheet
the execution needs less time (almost instant) as the necessary values are yet known and saved !
Until the Windows screen display dpi, the paper size, the orientation, a margin or the source columns range width is changed …
Once it's executed for a sheet like your 2 columns attachment, if you open on the same computer another workbook
like for example the 3 columns the execution will be faster than the first launch as the usable width is yet saved,
the procedure just needs to evaluate the columns blocks # and the blank column width.
The Mixed procedure to see in next post …