I am using the standard table component in Perspective and configured a column for editing. The user needs to update the same column for multiple rows of a table. The default behavior is click on the column to edit, enter a value, press enter and then move onto the next row and do the same thing.
Is there a way to modify the behavior so a user can click on the column to edit, enter a value and then click on the same column in the next row and eliminate the user having to press enter after each edit?
I tried to use the onEditCellCancel event but the event.value property has the original value from the table rather than the value the user typed in. Is there any way to pick up the value the user entered?
Is there a different way to solve this problem?
I ran into this before when rendering a boolean value as a checkbox in the table and making it editable. There was an awkward 2 - 3 clicks on the cell to be edited to make it smooth, so what I ended up doing was using a separate view (very simple, just a checkbox and a few incoming parameters) and then rendering the column as a view and passing the viewPath to your simple checkbox (or text entry) view.
This approach might make it easier for you, but it still doesn't answer the question on how you'll be writing the changed value in the embedded view back to the table's prop.data. This isn't difficult to do (all it takes is accepting some parameters from your table cell like rowId and columnId to use in a message handler to then set the props.data[rowId][columnId] to your new value. The only thing that isn't clear in my mind is how you'll know when to send the message - I suppose you could use a mouse leave event or something along those lines.
Let me know if any of that makes sense...
2 Likes
For booleans, instead of an embedded view, you can use a onRowClick (or something like that) event script on the table to switch the value.
Something like (warning: pseudo code)
self.data[selectedRow][selectedColumn] = not self.data[selectedRow][selectedColumn]
For other data types, the embedded view seems to be the solution - an embedded text field allows for settings that the basic table cell doesn't, like deferUpdates for example, which might be just what @Frank_L is after.
1 Like
Yeah, you would think setting the cell or row to editable would do it, but in practice (unless something changed recently), it takes 2 or 3 clicks on the checkbox to change it's value. I believe the first click is selecting the cell and then the second click toggles the checkbox. I didn't like that the last time I had a situation like this, which is why I used an embedded view to get the behavior an operator or user expects.
Again, things may have changed since then - I'd have to set up an example and see if that's still the case.
Which is why you add the script I posted. It makes it seamless.
The editable property alone is not enough.
Ahh, I see what the purpose of the script is. I believe you should filter the selectedColumn to only include your boolean column, but otherwise, that is cleaner than using an embedded view and message.
[If you don't filter out the selected column, you'll get any table cell updating to not it's value, which is not well defined for certain data types]
This was only an approximation of the actual script, so yes, you might need some additional logic to restrict the execution of this line to some columns. This exercise is left to the reader 
Note: you can also use the opportunity to add more logic, for example I have a table that allows the user to select days of the week for particular items/machines. They wanted some special selection rules: clicking a day should apply the same value to all the following days. Easily done right there in the script.
1 Like