Hello, I am using a grid with cell edit and it is common for each cell to have its own determination of if it is editable. So not only per column, but based on other data in the row. This is mostly fine, as I use a function bound to [editable] which tracks the current row in order to not only decide if the column as a whole is editable, but if the specific cell in that column is based on the row. This becomes an issue when the very last editable column affects this dynamic editability.
In the below example, the cells in green are editable, in red are not, and that is determined by that Locked checkbox, which is always editable. Locked also happens to be the last editable column in the row, and so in edit mode, if you were to check the box and hit tab, the grid immediately determines that all those cells before in that row are uneditable (which is true for that row) before it moves to the next row and thus it will skip focus to the Locked column of the next row.
I looked at the source code and it appears that the tab listener where it calls getNextCell will run the code for determining editable columns (using whatever is bound to [editable]) before it runs endCellEdit or beginCellEdit on the cells you are leaving/going to. This means that logic is called on the row you are on, not the row you are going to. By the time BeginCellEdit of the next row runs, it has already decided that the Locked column is the first editable column, despite the fact that if it ran that logic again, previous columns should now be editable.
I have tried many ways around this and cannot think of anything that wouldn't be a terrible hack. Am I missing some other way to do this?
Thank you, I believe this concept should work for me. It isn't ideal that it essentially bypasses how the cell edit grid would normally function, but it may end up being cleaner because we have had to add a lot to the cellEditEnter and CellEditExit in order to handle weird edge scenarios. I can still use most of that logic but only triggered by this gridkeydown event. The piece I was missing was I tried a normal keydown event which doesn't know about the cell you are in, where this gridkeydown fills in that piece. Thank you for your detailed response and example.
Hi Matt,
Thank you for contacting Infragistics Developer Support!
I have been looking into your description and tried to recreate a similar setup in this sample. I think I managed to achieve something similar. An unknown piece that remains is how the columns have their editable property bound – what is the function and its parameters? This may be a crucial part of the scenario and could be related to any unexpected behaviors.
Nevertheless, the sample suggests an approach, possibly different than yours, to achieve what I understand is your requirement – tab navigation among only the editable cells, which can also dynamically change.The solution involves handling the gridKeydown event for the ‘tab’ and ‘tab + shift’ combinations and essentially overriding the navigation logic in these cases by seeking for the next or previous editable cells. Please, refer to the sample .ts code for the implementation details.The cellEditEnter event of the grid is also handled to cancel entering edit mode for a non-editable cell (by clicking). That is, since the editable property of the column is left as 'true' and the edit mode is rather programmatically handled. The sample also leverages the cellClasses to style the cells as red/green.
In conclusion, please, check out the sample and let me know if it helps. Please, feel free to further adjust it based on your existing logic. As an application-level solution, also make sure to fully test it against edge scenarios.
Best regards,Bozhidara PachilovaSoftware Developer
The image I attached is not appearing, hopefully my description is enough to get the context of the issue.