https://bugs.documentfoundation.org/show_bug.cgi?id=151840
--- Comment #8 from Lionel Elie Mamane <lio...@mamane.lu> ---
(In reply to Mike Kaganski from comment #7)
> First of all, cursor is not a table. Implementing XTextTable in the cursor
> would be a wrong mix of concepts.
I technically agree with the narrow statement above, but I see no "wrong mix of
concept" in that the TextTableCursor can give access to the table it is a
cursor in. Which you also propose, through a TextTable property or a
getTextTable() method (which Basic would "present" as a read-only TextTable
pseudo-property).
However, I must stress that, as far as I can observe, css:text:TextTableCursor
is returned by ThisComponent.getCurrentSelection() only when a range of cells
is selected. In that case, it seems css:text:CellRange is the service that was
thought out for this case, and makes sense. Whether the object returned by
getCurrentSelection() implements that service, or has a property containing an
object that implements that service, I can be live with either.
> Then, in the context of *writer's* (in general case) non-rectangular tables,
> "number of selected columns" makes no sense at all, and pretending that it
> makes sense by providing respective API would be wrong.
Consider this code:
dim rngName as String
rngName = oSel.getRangeName()
dim rngPoints(2) As String
rngPoints = split(rngName, ":")
dim frstCol, lastCol as Long
frstCol = convert_letters_to_number(rngPoints(0))
lastCol = convert_letters_to_number(rngPoints(1))
MsgBox(lastCol - frstCol + 1)
That is _currently_ the notion of "number of columns selected" that the cursor
_already_ has. One would just provide saner/easier access to the same
information. Some of the cells may be split and thus some rows in the range
have more columns that the calculated value? That's just the nature of text
tables, which the programmer will have to deal with.
The LibreOffice UI presents the user with a notion of column and a notion of
row. *Something* happens when one right-clicks on a cell and chooses "Delete /
Delete Columns". Similarly, the cursor on the edge of a table becomes an arrow,
and then clicking selects what is identified, in the UI, as a row or a column.
> Then, the TextTable property would not represent the selection, but the
> whole table (that has *some* of its cells selected). In that view, it's
> unclear how much this code makes sense:
> oCellRange = oSel.TextTable.getCellRangeByName(oSel.getRangeName())
> because, say, oSel.TextTable could be a 3-row table with first and third
> rows having 5 cells, and second row having 2 cells; and oSel.getRangeName()
> could be "B1:D3" - what is there in 2nd row selected?
I believe that _is_ well-defined within LibreOffice, at least at the UI level.
The definition might not be straightforward, it might not be easy to understand
or immediately intuitive, but it is there. The UI doesn't let one select any
set of rows, only "generalised rectangles", which can be expressed as "LD:LD"
where L is letters and D is a digits. The selection is shown in this syntax in
the status bar (along with the name of the table).
So to get the answer to your example, just put the mouse pointer in the B1
cell, press the mouse button, go to the D3 cell and release the mouse button.
That's the "B1:D3" selection and getCellRangeByName("B1:D3") should (and I
expect already does) refer to the same range.
Answering your question cannot be done, because it is underspecified, it
depends on the fine structure of the table.
> Does getCellRangeByName do the same as mouse selection?
Yes, we have to be consistent. Mouse selection calls that "B1:D3", why have a
different understanding of the same string?
> In that case, enumeration access makes the most sense.
It can make sense, but people will need to access the 2D structure of the
table. Since text tables are "weird", they _will_ get weird corner cases if
they expect to operate on arbitrary text tables. We _should_ provide them the
API access to be consistent with the UI behaviour, with the same notion of
column of "generalised rectangle", etc.
--
You are receiving this mail because:
You are the assignee for the bug.
