If a cell has the focus and the cell is for a column that is marked as non-editable or the editCellStarting returns false for any reason, the keyboard navigation no longer works and the user is "stranded" on that cell.
I have reproduced the issue in this example by clicking on the unit price column and then trying to tab forward or backward.
The key here is that rowEditing be turned off
It is a very common scenario for us to use editCellStarting to disable a specific cell in a row even though the column is turned off. Our users rely heavily on keyboard navigation, so this is a critical issue for us.
Hello Lance,
By default when Tab is pressed in a cell in edit mode, the focus is moved to the next editable cell, however, if the cell is not in edit mode and tab is pressed by specification the focus is moved out of the grid. In order to navigate through the cells in a grid without entering edit mode the left and right arrows should be used.
However, a custom navigation could be implemented, in order to move through the cells using Tab key. This could be achieved by binding a method to the keydown event:
public keydown(evt) {
if(evt.keyCode == 9 && !this.grid1.getCellByColumnVisibleIndex(this.activeCell.row, this.activeCell.column)?.editMode) {
evt.preventDefault();
if(evt.shiftKey) {
let prevPosition = this.grid1.getPreviousCell(this.activeCell.row, this.activeCell.column);
this.grid1.navigateTo(prevPosition.rowIndex, prevPosition.visibleColumnIndex);
this.grid1.getCellByColumnVisibleIndex(prevPosition.rowIndex, prevPosition.visibleColumnIndex)?.activate();
} else{
let nextPosition = this.grid1.getNextCell(this.activeCell.row, this.activeCell.column);
this.grid1.navigateTo(nextPosition.rowIndex, nextPosition.visibleColumnIndex);
this.grid1.getCellByColumnVisibleIndex(nextPosition.rowIndex, nextPosition.visibleColumnIndex)?.activate();
}
More information regarding keyboard navigation could be found in the following topic.
I have prepared a sample, demonstrating the described behavior. Please test it on your side and let me know if you have any additional questions.
Regards, Monika Kirkova, Infragistics
While I appreciate the response and sample, I cannot believe that this is acceptable behavior.
The grid allows us to cancel editing when the user arrives at a cell, which means that simply using standard grid behavior can result in a completely unacceptable user experience.
I understand that this is the designed behavior of the grid, but in my opinion, having worked with Infragistics grids for close to 20 years and other vendor grids for 15 or more, this is not acceptable behavior.
In addition, the sample doesn't actually compile on our current version (10.2.3, I think): activate requires a keyboard event.
We have had to override the standard navigation service's handleNavigation method to address some other issues in the grid (trying to navigate while in the details area, pressing enter in a textarea while editing a cell), so we have just extended this functionality to also support tabbing off of a cell that is not editable.
This support includes determining whether the column is not editable or the cell could not enter edit mode because of rules enforced in cellEditEnter.
In addition to setting focus on the next tab, we also call the method associated with onCellClick to ensure that this cell navigation is treated like tabbing from an editable cell.
Basically:
const activeNode = this.grid.navigation.activeNode; let newCellPosition: ICellPosition; if (event.shiftKey) { newCellPosition = this.grid.getPreviousCell(activeNode.row, activeNode.column); } else { newCellPosition = this.grid.getNextCell(activeNode.row, activeNode.column); } this.grid.navigateTo(newCellPosition.rowIndex, newCellPosition.visibleColumnIndex); const newCell = this.grid.getCellByColumnVisibleIndex(newCellPosition.rowIndex, newCellPosition.visibleColumnIndex); if (!newCell) { return; } newCell.activate(event); this.handleCellClick(newCell); event.preventDefault();
I am glad, you were able to achieve your requirement.
Additionally, the grid keyboard navigation is following the ARIA specification. According to the specification, a primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another. While other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements.
Thank you for using Infragistics components.
Thank you again for the response. Unfortunately, users don't really know or care about specifications, they care about getting their job done as efficiently as possible.
The suggestion that using arrows to navigate isn't practical at all and requires the user to use two different navigation mechanisms depending on the element that currently has focus.
For example, if I am editing a date field and press the right arrow, the cursor simply goes to the end of the date, not to the next cell. However, tab does go to the next cell.
Based on this behavior, either the writers of the specification have never actually used a component like a grid or the Infragistics implementation does not meet the implementation.
I have been working with Infragistics and other vendor grids for more than 20 years, and this is the first time that I have had this explanation given for this type of behavior.