I found a bug in the column count calculation if the grid's AutoExpand flags do not contain the flag aeDefault. I hope the fix has no sideeffects because I had to touch this location already several times...
Tested with r5861.
But BTW, the flag aeDefault is not needed in your case anyway. It is needed when loading files that occupy only a few cells and you want the grid to expand to get a "spreadsheet" look & feel. In your case, setting the ColCount should be enough.
Actually the demo was derived from a case where the WorksheetGrid was intended as a TStringGrid alternative (therefore the ShowHeaders = false). So, the - [aeDefault] is relevant here.
This thread is becoming complicated. The CellEdit was introduced in the demo before you released the multiline grid cell editor. In my application I removed the CellEdit, so now I can re-insert the "AutoExpand := AutoExpand - [aeDefault]" statement (I think).
In the later demo I left the CellEdit in because it demonstrates a problem.
The internals of fpspreadsheet and underlying layers are encapsulated for me as an applications programmer - lucky for me and others.
But it seems that we try to have one implementation that should satisfy two conflicting cases: the WorksheetGrid as close as possible to an Excel worksheet, and the WorksheetGrid as a superior dedicated TStringGrid. Just an idea: could it be simpler to make two seperate classes: a WorksheetGrid (first case) and a "WorksheetStringGrid"?