Difference between revisions of "Documentation/DevGuide/Text/Tables"
OOoWikiBot (Talk | contribs) m (Robot: Changing Category:Documentation/Developers Guide/Text Documents) |
OOoWikiBot (Talk | contribs) m (FINAL VERSION FOR L10N) |
||
| Line 6: | Line 6: | ||
|NextPage=Documentation/DevGuide/Text/Named Table Cells in Rows, Columns and the Table Cursor | |NextPage=Documentation/DevGuide/Text/Named Table Cells in Rows, Columns and the Table Cursor | ||
}} | }} | ||
| − | {{DISPLAYTITLE:Tables}} | + | {{Documentation/DevGuideLanguages|Documentation/DevGuide/Text/{{SUBPAGENAME}}}} |
| + | {{DISPLAYTITLE:Tables}} | ||
=== Table Architecture === | === Table Architecture === | ||
Revision as of 10:08, 14 May 2009
Table Architecture
OpenOffice.org text tables consist of rows, rows consist of one or more cells, and cells can contain text or rows. There is no logical concept of columns. From the API's perspective, a table acts as if it had columns, as long as there are no split or merged cells.
Cells in a row are counted alphabetically starting from A, where rows are counted numerically, starting from 1. This results in a cell-row addressing pattern, where the cell letter is denoted first (A-Zff.), followed by the row number (1ff.):
| A1 | B1 | C1 | D1 |
| A2 | B2 | C2 | D2 |
| A3 | B3 | C3 | D3 |
| A4 | B4 | C4 | D4 |
When a cell is split vertically, the new cell gets the letter of the former right-hand-side neighbor cell and the former neighbor cell gets the next letter in the alphabet. Consider the example table below: B2 was split vertically, a new cell C2 is inserted and the former C2 became D2, D2 became E2, and so forth.
When cells are merged vertically, the resulting cell counts as one cell and gets one letter. The neighbor cell to the right gets the subsequent letter. B4 in the table below shows this. The former B4 and C4 have been merged, so the former D4 could become C4. The cell name D4 is no longer required.
As shown, there is no way to address a column C anymore, for the cells C1 to C4 no longer form a column:
| A1 | B1 | C1 | D1 | |
| A2 | B2 vertically split in two | C2 newly inserted | D2 | E2 |
| A3 | B3 | C3 | D3 | |
| A4 | B4 merged with C4 | C4 | ||
When cells are split horizontally, OpenOffice.org simply inserts as many rows into the cell as required.
In our example table, we continued by splitting C2 first horizontally and then vertically so that there is a range of four cells.
The writer treats the content of C2 as two rows and starts counting cells within rows. To address the new cells, it extends the original cell name C2 by new addresses following the cell-row pattern. The upper row gets row number 1 and the first cell in the row gets cell number 1, resulting in the cell address C2.1.1, where the latter 1 indicates the row and the former 1 indicates the first cell in the row. The right neighbor of C2.1.1 is C2.2.1. The subaddress 2.1 means the second cell in the first row.
| A1 | B1 | C1 | D1 | ||
| A2 | B2 vertically split in two | C2.1.1 | C2.2.1 | D2 | E2 |
| C2.1.2 | C2.2.2 | ||||
| A3 | B3 | C3 | D3 | ||
| A4 | B4 merged with C4 | C4 | |||
The cell-row pattern is used for all further subaddressing as the cells are split and merged. The cell addresses can change radically depending on the table structure generated by OpenOffice.org. The next table shows what happens when E2 is merged with D3. The table is reorganized, so that it has three rows instead of four. The second row contains two cells, A2 and B2 (sic!). The cell A2 has two rows, as shown from the cell subaddresses: The upper row consists of four cells, namely A2.1.1 through A2.4.1, whereas the lower row consists of the three cells A2.1.2 through A2.3.2.
The cell range C2.1.1:C2.2.2 that was formerly contained in cell C2 is now in cell A2.3.1 that denotes the third cell in the first row of A2. Within the address of the cell A2.3.1, OpenOffice.org has started a new subaddressing level using the cell-row pattern again.
| A1 | B1 | C1 | D1 | ||
| A2.1.1 | A2.2.1 | A2.3.1.1.1 | A2.3.1.2.1 | A2.4.1 | Former E2 merged
with former D3 Becomes B2! |
| A2.3.1.1.2 | A2.3.1.2.2 | ||||
| A2.1.2 | A2.2.2 | A2.3.2 | |||
| A3 | B3 | C3 | |||
Cell addresses can become complicated. The cell address can be looked up in the user interface. Set the GUI text cursor in the desired cell and observe the lower-right corner of the status bar in the text document.
Remember that there are only "columns" in a text table, as long as there are no split or merged cells.
Text tables support the service com.sun.star.text.TextTable, which includes the service com.sun.star.text.TextContent:
The service com.sun.star.text.TextTable offers access to table cells in two different ways::
- Yields named table cells which are organized in rows and columns.
- Provides a table cursor to travel through the table cells and alter the cell properties.
These aspects are reflected in the interface com.sun.star.text.XTextTable which inherits from com.sun.star.text.XTextContent. It can be seen as a rectangular range of cells defined by numeric column indexes, as described by com.sun.star.table.XCellRange. This aspect makes text tables compatible with spreadsheet tables. Also, text tables have a name, can be sorted, charts can be based on them, and predefined formats can be applied to the tables. The latter aspects are covered by the interfaces com.sun.star.container.XNamed, com.sun.star.util.XSortable, com.sun.star.chart.XChartDataArray and com.sun.star.table.XAutoFormattable.
The usage of these interfaces and the properties of the TextTable service are discussed below.
| Content on this page is licensed under the Public Documentation License (PDL). |
