Listening to Grid.EditorMoveEvent

[ClarenceSmithson]

I request a method to trap (listen to) Grid.EditorMoveEvent be made available to achieve it from the Server side. If it can currently be done can you please advise how, as EditorListener does not work.

I have seen previous replies to posts related to this issue that EditorListener was "dropped" because it does not work in Java 8. I understand that alternatives were suggested to achieve this from the client side however I request for the option to trap this event from the Server side.

The background is as follows. I use the Grid in a layout which provides a menubar where an Update menu, which has an Unlock sub-menu, becomes available only when the user selects a row. If the user selects Unlock, I start the editor with with the following sequence:

sqlc.setAutoCommit(false); // sqlc is the SQLContainer set as the data source for grid grid.setEditorEnabled(true);
final NonNullFieldGroup nonNullFieldGroup = new NonNullFieldGroup(); // a FieldGroup which suppresses the word null being shown in empty cells grid.setEditorFieldGroup(nonNullFieldGroup); grid.setEditorBuffered(false); grid.editItem(selectedRow); // selectedRow is the itemId of the clicked row

When the user is finished with changes, the menubar offers Commit Update or Cancel Update submenus and the changes are committed or rolled back according to user selection in the respective methods.

When the Editor is set in unbuffered mode as above for a Vaadin Grid, I have observed that not only that editing is much more "elegant" as it is "in line" with no separate editor pane being opened, you can even edit multiple rows without setting the selection mode to Multi, thus avoiding a tickbox column and making the UI simple and elegant for the user, like a spreadsheet. The only problem is that as the user moves from row to row the changes made to earlier rows vanish from the view, (the original values are displayed again) although the changes are "there" and if the user then presses the Commit Update menu they are made.

All I want is to somehow keep the changes visible as the user moves from row to row. I think this can be done by trapping the EditorMoveEvent. In there I will use grid.clearSortOrder which makes the changed values visible. I have observed that after grid.editItem(selectedRow); is executed, grid.addItemClickListener and grid.addSelectionListener events do not fire when the user clicks on a new row to edit it.

I have observed that grid.addFocusListener event does fire so I have tried to accomplish my objective with grid.addFocusListener, and the changes do become visible as I use grid.clearSortOrder in the event method. However I have observed that if the user presses the tab key to move between cells, and at times even if he uses the mouse to move between cells, the user can lose cell focus while editing and the row can become uneditable until the user presses a double click on it! This must be happening as this event itself would be firing due to user movements within the same row. I would like to avoid this behaviour and I believe this can be accomplished if the EditorMoveEvent could be trapped and used, as that event should not fire till the user moves to a new row.

[TatuLund]

Have you tried Grid FastNavigation add-on https://vaadin.com/directory#!addon/gridfastnavigation-add-on as a workaround?

[stale[bot]]

Hello there!

It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!