Rows and Columns

Rows and columns are not symmetric in UniOffice, and that is what catches people out. A row is a real object: Sheet.AddRow returns one, you add cells to it, and the cells live inside it in the file. A column is not. Sheet.Column returns a Column, but its doc comment says it is only used for formatting purposes, and the type carries exactly three setters: SetWidth, SetStyle and SetHidden. There is no list of values behind it. To write down a column you write a cell into that position in every row.

That asymmetry runs through the whole package. There is AddRow, InsertRow and Row, but no AddColumn or InsertColumn. There is RemoveColumn, but no RemoveRow. Column definitions are also indexed differently from cell references: Sheet.Column takes a 1-based index while reference.ColumnToIndex maps A to 0.

Structural edits move data

Inserting a row pushes everything below it down. Removing a column pulls everything to its right left. Both rewrite the cell references of the data that moved, so the sheet itself stays consistent. What differs is whether anything pointing at that data gets fixed too.

RemoveColumn is the only one of the three that reparses formulas. It walks every sheet in the workbook, shifts references that sat right of the removed column, turns references to the removed column itself into #REF!, and then recalculates. InsertRow and Sort move the data and leave every formula exactly as written, which means a formula that referred to a moved cell now refers to whatever took its place. Add formulas after the structural edits, or fix them yourself.

Freezing is the odd one out, and the safe one: a sheet view setting that changes nothing about the data at all.

Volume is the other thing worth knowing before you start. The whole workbook is held in memory until you save, and AddRow and AddCell each have a fast path that only fires when you append in order, so a generator that writes top to bottom and left to right stays linear where one that jumps around does not.

Where to look