Table column insertion changes caret and scroll position to wrong place

[vitorhugovm]

Hello,

I'm currently using Oxygen XML Web Author with SDK version 25.1, with a custom framework and editing an XML document.

I'm having trouble while inserting a table column. When I run InsertSingleColumnOperation or in some cases of SplitOperation, the caret position is altered to a random element written way above the table, while the scrollbar goes to the top of the screen.
Is there a way to avoid or treat this behavior?

Thanks!
Vitor

[cosminef]

Hello,

Can you help us with the following information?:

• Send us the framework you are using.

• A sample file for us to test the issue that occurred.

• Steps to reproduce the problem.

Best,
Cosmin

[vitorhugovm]

Hello Cosmin!

I'm sorry, for compliance reasons I cannot send you our framework.
I'm using the S1000D schema to edit the XML documents.

The following code is being used in JavaScript to call the table action through an action button:

Code: Select all

class DeleteTableColumn extends sync.actions.AbstractAction {

  constructor(editor) {
    super();
    this.editor = editor;
  }

  /** The display name of the action */
  getDisplayName() {
    return 'Insert Table Row Below';
  }

  /** The display icon of the action */
  getLargeIcon(devicePixelRation) {
    return sync.ext.Registry.extensionURL + 'resources/icons/DeleteColumn24.png'
  }

  /** The display description of the action */
  getDescription() {
    return 'Delete the selected table column.';
  }

  // The action is enabled only if there is some content selected.
  isEnabled() {
    let nodeAtSelection = this.editor.getSelectionManager().getSelection().getNodeAtCaret();
    let nodeEnable = new ElementNode(nodeAtSelection);

    return nodeEnable.isChildOf("row");
  }

  // The actual action execution.
  actionPerformed(callback) {
    this.editor.getActionsManager().invokeOperation(
      'com.oxygen.embraer.tpms.cals.table.TableAuthorOperation', {
      action: 'deleteTableColumn'
    }, callback);
    callback();
  }
}

The invoked operation is a Java factory that leads to the following function:

Code: Select all

public void insertTableColumn() throws AuthorOperationException {
    InsertSingleColumnOperation insertColumn = new InsertSingleColumnOperation();
    insertColumn.doOperation(this.authorAccess, this.args);
}

After this default operation is completed, the screen is scrolled to the top and the caret is sent to a wrong position. The same happens with SplitOperation when it needs to insert a new column.

Thanks for the attention!
Vitor

[mihaela]

Hello,

From what I understand the caret position is changed after the table operation is invoked.
The operation that you use (com.oxygen.embraer.tpms.cals.table.TableAuthorOperation) does not contain any code that changes the caret position at the end of the insert row or delete table action?

Best Regards,
Mihaela

[vitorhugovm]

Hello Mihaela!

Our code only calls the Oxygen default operation and does not perform by itself any change of caret or scroll.
As a reminder, we are using a default XML from S1000D, not a DITA. Apparently in DITA this does not happen.

Thanks!
Vitor

[mihaela]

Hello,

By "the Oxygen default operation" you understand ro.sync.ecss.extensions.commons.table.operations.cals.InsertColumnOperation for example?
This operation tries to place the caret in the first leaf of the inserted fragment.
Can you check the logs [1] to see if there is an error that happens when the document is scrolled?

[1] https://www.oxygenxml.com/doc/versions/ ... oting.html

Best Regards,
Mihaela

[vitorhugovm]

Hello!

Yes, I am using both ro.sync.ecss.extensions.commons.table.operations.cals.InsertColumnOperation and ro.sync.ecss.extensions.commons.table.operations.cals.SplitOperation as they are.
I tried logging to check for errors, but none is returned.

Thanks!
Vitor

[mihaela]

Hello,

I'm afraid I cannot help you further if I do not have access to your framework and a small sample to reproduce the problem.
We do not need the entire framework, we could just use a minimal variant that can be used to debug this issue (if you think it is ok, you can send the files on our support email address support@oxygenxml.com).

Best Regards,
Mihaela