AutoFit columns


 Hi,

 Is there any compact and working solution to auto fit columns like in excel selecting the whole worksheet and double click on any title edge?
 I can see a ton of overloaded txlsfile.autofit(<lot of stuff here>) and i admit i didn't try just one with (1, 10, false, 1) but the result is far below my expectations.

And i think at least "IgnoreStrings" and "adjustment" could have a default value in the declaration....

Regards

 Ok, looks like CalcCellWidth calls RenderFactory.SplitText without checking if the multi line text is
 displayed without wordwrapping.

Hi,
The complexity is sadly given by the complexity of the task, which seems simpler than it is at first sight. As mentioned in http://www.tmssoftware.biz/flexcel/docs/vcl/UsingFlexCelAPI.pdf (page 14) the Autofit in Excel isn't really perfect either, the size of the columns depends in the zoom of the page. (And of course, in printing the columns are wider than on screen, so some text that autofits well when you do a print preview, will show cut in the screen).

I agree that IgnoreStrings could have a default value, but seriously, adjustment is something you really need to consider because it is not the same in all the cases. When you for example want to export to pdf and don't care about the xls/x file itself, a value of 1.0 is fine. PDF is resolution independent so stuff doesn't look different in the printer and in the screen, so we can calculate exactly the width needed for the column.

But for exporting to xlsx, sadly Excel shows different sizes everywhere, depending in the printer, the screen scaling, etc. So you might autofit and make it look nice in your monitor, but your client will see the text cut. This is why you need some "adjustment" to give room to differences when you print, or your customer prints in a different printer, or you open Excel at 192 dpi instead of 96.

But the amount of adjustment is up to you. I normally select 1.2 or 1.3, but the bigger you make it the more blank space that there will be in the columns.

Have you tried:
(1, 10, false, 1.2)?
Does it look bad with those values?


 Thx for the insane fast reply.
 My problem was rather the case that the cell has 'bla'#13#10'bla' (which i didn't noticed) and excel displays in one default-height cell 'blabla' and flexcel autofits for:
'bla'
'bla'.

But now i understand where the problem is and i can get it around.
This could be improved eventually, but at some point, as you say, it's getting so complicated that it's not the worth aymore.


Are you referring to a cell which has enters inside, but is not set to wrap text?

If that is the case, indeed we will not autofit this, but to be fair Excel itself also doesn't autofit well a line that has enter but no word wrapping (it has empty space at the end of a cell). I just tried it here, and in Excel a cell with enters autofits to 23.47 while the same text with the enters removed (the string shows the same) autofits to 19.93

But I'll see to add support for multiple lines when text wrap is off. I'll let you know when it is ready.


  The text i exported is fitted to the same width with and without returns.
  Then i tried with manual entered values, the widths differ a bit as in your case.
  At least consequent inconsequent ;)

  Anyway, i think an "if" for wantwrap before splitting is a good idea.

  Thank you for your help.

Hi,
Just to let you know that we released 6.13.1 now and it should now correctly autofit cells with enters inside which are not in wordwrap. Of course the best is not to have such beasts in first place of course :)

Experimenting with Excel I discovered that while it handles "kind of right" enters and not wordwraps, it goes completely crazy if you format some part of the text inside.
Just for amusement here is a little gif I just recorded in Excel 2016, where I try to autofit a column which has 2 characters in bold:


But worry not, FlexCel should handle formatted text just fine. In any case, as mentioned, if possible the best is not to put enters inside cells that won't wrap, they serve no purpose and can complicate things.


 Nice catch ;)
 Thank you for the patch, now it works with 1.1 like a charm!

 Best regards