https://bugs.documentfoundation.org/show_bug.cgi?id=160784

Mike Kaganski <mikekagan...@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|regression                  |
         Resolution|---                         |NOTABUG

--- Comment #8 from Mike Kaganski <mikekagan...@hotmail.com> ---
In fact, this is not a regression. This is a user error in using the API.
The relevant Java code is:

    // getRangeFromTable
    final XTextRange xStartTable = xTextTable.getAnchor().getStart();

    ...

    // moves the cursor to the line right before the table
    textViewCursor.gotoRange(xStartTable, false);

    ...

    // moves the cursor to the end of the line right before the table
    xCursor.gotoRange(textViewCursor.getStart(), false);

This code relied upon an unspecified behavior when using the result of getStart
in a way that is explicitly described in the documentation [1] as wrong.
Specifically:

> Note: The anchor of the actual implementation for text tables does not have a
> position in the text. Thus that anchor can not be used for some operation like
> attach() for example or com::sun::star::text::insertTextContent or other
> function that require the object to have a position in the text.
> 
> The reason why a text table still needs an anchor is that for example tables
> should be insertable via com::sun::star::text::insertTextContent and that
> interface uses a parameter of that type.

So, again: the result of XTextTable::getStart is *not* a specific position in
text, and it can't be used in the XTextViewCursor::gotoRange call, which needs
a position in text. The previous (unspecified) behavior was to move the cursor
outside of the table in that case; the current (also unspecified) behavior is
to move into the first cell. So when the following XTextCursor::gotoRange tries
to move a cursor that belongs *to a body text* into a table, this fails (and
that is OK).

This code may be improved to work in both cases. Specifically:

1. Fix getting the position before the table: after the line

        // moves the cursor to the line right before the table
        textViewCursor.gotoRange(xStartTable, false);

insert these lines:


        while (textViewCursor.getText() != xText)
        {
            textViewCursor.goLeft((short)1, false);
        }

This makes sure that if textViewCursor ended up inside the table, it moves
outside. At the same time, in previous versions, this won't change the
behavior.

2. Instead of lines

        textViewCursor.gotoRange(xEndTable, false);
        textViewCursor.gotoEnd(false);

insert this line:

        textViewCursor.goRight((short)2, true);

This selects the just-selected filed before the table, and also the next object
- which is the table (which can only be selected as a whole). This makes the
end of the selection to be immediately after the table.

[1]
https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1text_1_1XTextContent.html#ae82a8b42f6b2578549b68b4483a877d3

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to