https://bugs.documentfoundation.org/show_bug.cgi?id=151840
--- Comment #5 from Mike Kaganski <[email protected]> --- (In reply to Lionel Elie Mamane from comment #3) > This is a table, it has a 2D structure. That structure should be accessible > as such in the API. ... (In reply to Rafael Lima from comment #4) > I would also support the implementation of XCellRange, since it provides > access by row/column. ... No, it doesn't work that way ;) It's not OK to implement whatever interfaces *could* be nice to have; there should be a reason to add anything. For example: why do I need a TextTable property, or XEnumerationAccess. Consider the code: oSel = ThisComponent.CurrentSelection If (HasUnoInterfaces(oSel, "com.sun.star.text.XTextTableCursor")) Then ' I want to get the table object where oSel is in; I can only do that ' using a workaround now: oViewCursor = ThisComponent.CurrentController.getViewCursor() oTab=oViewCursor.TextTable ' I need to iterate the selected cells, without any specific order; ' say, I need to format the paragraph inside... oCellRange = oTab.getCellRangeByName(oSel.getRangeName()) ' ... End If If I had either of the things I mentioned, the task would become easier; and additionally, the XTextTableCursor could arrive not only from selection, but also from some programmatic way, without having corresponding view cursor, which would make the task impossible. So if you think there should be something new implemented, there should appear some specific discussion which scenario is simplified (or even becomes possible) with the new stuff, and why it is relevant. -- You are receiving this mail because: You are the assignee for the bug.
