Hi, i have a table whereby one of the column has viewPath and viewParams configured.
The view is just a simple MultiStateButton with selections available.
So instead of having the user to key in manually,they can select directly from the 3 options available.
Now, when the user clicks on the cell to edit, the cell becomes a input field, instead of making the buttons available for the user to choose from. It defeats the purpose of having a customized view then…
Could someone point out where did i go wrong? Am i missing out any settings or scripting?
You will need to set up the props.columns list property on your table component if you have not done so already. Once that is complete, I think your column that is rendering the view containing the multistate button just needs to have its “editable” property set to false:
Hi @swolnisty, yes, my “editable” property was set to true, which is why the input field was displayed instead. Thank you!
But hmm… doesn’t the property “editable” indicates if the column is editable?..
So if i set it to editable, meaning only then i would be able to edit/write right?
If it is set to false, and yet the view inside is able to edit/write, isnt it misleading?
Hmm, i guess i have understood it wrongly…
2 Likes
I think the intent behind the term “editable” here is that when set to true, a user would be able to click into the cell of a table and directly edit the value of the cell by typing a new value. This is a little counter-intuitive when you set a column of cells to render a view with a component that users are meant to interact with, since clicking into one of those cells while the editable property is set to true will skip interaction with the embedded view’s components and instead allow the user to edit the value of the cell itself. By setting the column’s editable property to false, you are telling the table to not allow users to directly type in new values for each cell in that column, which has the side effect of allowing the interaction with the embedded view’s components to work as expected.
I can definitely see where the confusion can be, but hopefully that helps explain the way the component works in practice (or as best I can figure it does, at least).
Thank you for the explanation!
But i am facing another issue. I realised writing through the view is not working.
When i update the value directly from the tag browser, the multistate button reflects correctly, which means the view.params.value part is okay, pointing to the right place…
I have checked “Bidirectional” is ticked for multistate button’s controlValue and table data tag binding.
Tried setting the view.params.value as input and input/output.
But still i am unable to write… Something is missing… 
I have experienced some difficulty relying on parameters getting passed back from embedded view in table cells in the past as well. They do not always seem to perform the way that you would expect them to. I usually rely on sending messages triggered by property change scripts from within the embedded to message handlers in the view with the table instead of bidirectionally binding parameters. That concept is described in more detail in this thread.
Is there anything else than those multi-state buttons in your table ?
If not, maybe you could try using a flex repeater instead.
Hi @swolnisty, thanks for sharing the thread!
Hi @pascal.fragnoud , I still have to display checkbox and various columns of values etc… so i would have to stick to the table…
I managed to solve the issue.
So it appears that, even though i have set the param “value” to be input/inout type, and having the button’s controlValue linked bidirectional to it, when writing value from the table (clicking the button from the view) the button’s controlValue is NOT writing/pointing to the correct tag path in the first place…
(My table’s data are bound to UDTs with consistent tagname like Tank 1, Tank 2, Tank 3 etc.)
So instead of making the controlValue to bind to the value param, i linked it to an indirect tagpath instead.
The tagpath would be something like: [default]PLC/Tank {row}/thatspecificparameter
Since the “row” value would be auto generated by the table, starting with “0” for row 1, the expression edit would be {view.params.row}+1
With above configuration, im able to write from the table successfully.
I am not sure if my approach/understanding is correct, as i do not understand since the “value” is also something auto generated and passed from the table to the view, matching row by row, why isnt it not possible to write back as well?..
Writing back to the cell view’s “value” param may not be possible because it may only be set as an input param by default. If that’s the case, it might not even be possible to change the type of param it is, even if you pre-define “value” in the view as input/output beforehand. You would have to play around with that and see what the results are. I’m not very certain on any of the above, just pure guesswork. When configuring cells with embedded views in the past, I did not have much luck at all with bidirectional binding, even after setting params to be input/output, so I have stuck with the message handler approach, even though it takes a little more setup work up front. It is completely possible that the issues I was seeing with binding params could have related to bugs in earlier versions of Perspective that Inductive has since worked out; Perspective and its components have come a LONG way in the few short years since its launch. 