Is it possible to have the Perspective table component commit a cell edit on loss of focus like the vision table?
E: Nix this–I couldn’t produce a working example, which makes this bad advice. Please disregard. I couldn’t come up with a working example since there’s no reliable way to keep track of what the user has typed if they cancel a cell edit (as of 8.0.8).
Yes! (It is worth mentioning that you’ll be trading off the ability to actually cancel an entry with this first method. Using messages and handlers is probably the better bet. Sorry for the wall of text.) If you’re just looking for a way to commit once a user “cancels” a cell edit via escape key or by clicking elsewhere WITHIN the table, then all you need is a script on your table’s
onEditCellCancel event where you can use the same logic you’d use in your
onEditCellCommit event (which is a necessity if you’re editing your table anyway–you need to have logic to commit your changes or else the table won’t update). Be sure to check the table docs here for more on these events and editing tables in general if you haven’t already.
If you’re looking for a comprehensive way to commit when the user clicks anywhere OUTSIDE the table, you’re gonna have to do more legwork. In this case, here’s a way I’d do it: For every component/container on screen that you want the user to be able to click on to cancel/commit, use a system.perspective.sendMessage() in a script within that component’s
Create a message handler (Ctrl+K) on your table to receive these messages. Within this handler, put your logic for committing changes–likely the same as in your
onEditCellCommitcomponent event handler.
(As an aside, if you’re using the same logic in multiple places in a single component, it’s better to utilize a single message handler and just have your component events send a message that triggers the logic–e.g., in this case, have your
onEditCellCommit send the same message that your outside components are in their
onClick event rather than duplicating the code. That way, you only have one piece of code to maintain instead of two!)
As suggested I tried copying the code I had on the onCellEditCommit event script to the onCellEditCancel event script, but this just seem to place the old/pre-edit text back into the data property, if the user clicks into a cell and types some new text when they leave that cell by clicking into the next cell, it jumps back to the old pre-edit state and the new user input is lost.
I set up some logging and it appears the event.value property of the onCellEditCancel
event script only holds the cell value as it was before the edit was started, not the value at point of script execution.
self.props.data[event.row][event.column] = event.value
Yup, that’s an issue. My apologies. I incorrectly presumed that
onCellEditCancel would have the cancelled text value. I should have attempted more earnestly to make a solution before posting–my bad!
I’ve just spent an hour and a half trying to come up with a working example, but unless they add the in-progress text to the
onEditCellCancel event, or until they add/fix the text composition events, it seems like there’s not a good way to go about doing this.
Edit: That said, I think it’s a pretty reasonable feature request to be able to get the mid-edit text within an
onEditCellCancel event, which would solve our problem here.
Was there a discovered solution to this and/or any update if this was a feature being added in the future?
If the onEditCellCancel event argument contained whatever the user had inputted into the cell before the edit was canceled that would be very helpful. Does anyone know if this is on the radar of the development team, or if it could be a possibility in the future?
At the moment the only way to edit a cell in a table is by double clicking it, then writing the value and pressing enter key to store the new value, this is done with the “onEditCellCommit” event, can you confirm there is no way to store the new value when the focus on the cell is left, something like “onEditCellEnd” event?
I was able to get this functionality by making a view that was just a text field, then making a column render that view, and then binding the text to the passed value. From there you can commit whatever you need to as a change script on the text or use system.perspective.sendMessage() to send the value back to the parent view. It took some time to get right but ends up working rather well.