Forum Stats

  • 3,757,803 Users
  • 2,251,268 Discussions
  • 7,869,920 Comments

Discussions

Navigation From Table in Row Edit Mode exits Edit Mode without Cancel Event

DaveArch
DaveArch Member Posts: 102 Red Ribbon

JET Version: 10.0

Hi Community

Is anyone from the JET product team able to explain why when navigating outside an oj-table row that is in edit mode causes the on-oj-before-row-edit-end function to fire but with event.detail.cancelEdit property set to false.

We would expect that navigating out of the table row i.e. clicking/touching another part of the page would either not exit edit mode or if it did then event.detail.cancelEdit would be true.

Is there any way of finding out whether this navigation pattern has occurred? Essentially we want to cancel the edit in this case and not commit the change unless the user has positively confirmed the edit action is complete via a button.

Thanks

Best Answer

  • John 'JB' Brock-Oracle
    John 'JB' Brock-Oracle Posts: 2,658 Employee
    Accepted Answer

    The engineers have told me that it (event.details.cancelEdit) will always be false unless the user presses the Esc key.

    Edits are submitted on focus loss.

    I would use that dirtyFlag approach and veto any occurrence of the on-oj-before-row-edit-end, if that flag is still set to true, or the event.detail.cancelEdit value is false.  They would add a save/cancel button to the action field in the row and clear the dirtyFlag when that is clicked.

    if you use preventDefault on the event in the case where you don't want to exit edit mode, the Table will steal focus back, and you won't be able to do anything else on the page until the user either hits cancel or submit.

Answers

  • You should be able to listen for that on-oj-before-row-edit-end event and veto it if it hasn't exited via a specific pattern. Using a dirtyFlag variable, or by making sure that the event.detail.cancelEdit is true.

    I'll see if I can get an explanation of the code flow for this area and post it here as well, or have the engineer provide the answer directly.

  • DaveArch
    DaveArch Member Posts: 102 Red Ribbon

    Thanks John, that would be great.

    The problem we have is that within the on-oj-before-row-edit-end event, according to the cookbook, the only clue we have that the user has cancelled the update is event.detail.cancelEdit but this is false if a user has navigated outside the table, for example clicking somewhere else on the page in a desktop browser scenario.

    If there is something else in the event parameter that gives a clue to this then it would be very helpful.

    Thanks

  • John 'JB' Brock-Oracle
    John 'JB' Brock-Oracle Posts: 2,658 Employee
    Accepted Answer

    The engineers have told me that it (event.details.cancelEdit) will always be false unless the user presses the Esc key.

    Edits are submitted on focus loss.

    I would use that dirtyFlag approach and veto any occurrence of the on-oj-before-row-edit-end, if that flag is still set to true, or the event.detail.cancelEdit value is false.  They would add a save/cancel button to the action field in the row and clear the dirtyFlag when that is clicked.

    if you use preventDefault on the event in the case where you don't want to exit edit mode, the Table will steal focus back, and you won't be able to do anything else on the page until the user either hits cancel or submit.

  • DaveArch
    DaveArch Member Posts: 102 Red Ribbon

    Thanks John, your workaround works well.

    We set a variable in on-oj-before-row-edit listener to false and then set it to true in the listeners for the OK & Cancel buttons (we are using Editable Form Table). We then check that variable in the listener for on-oj-before-row-edit-end and only perform the row update if it is true. If a user navigates out of the edit row region without hitting OK or cancel, the variable remains false and the edit is ignored.

    We were unable to find a way to manipulate event.detail.cancelEdit from within the listeners for the OK & Cancel but the above solution works well so we will stick with that.

    Thanks again.