i have code on a table that is bound to a dataset which, in turn, generates the table contents. the table displays true or false for boolean values. we need toggle switches instead so we can change that state. i have no idea how, or even IF, this can this be done.
booo!!
yaaaay!!
the bottom image, is from the prototype i built in HTML a few weeks ago.
i fully recognize this may require more information, but i don't know what to give you at this point, so let me know and i'll amend the post as needed.
ok! that's fantastic! thank you. now: how do i get it to respond to clicks so as to change it's state? i set the column prop editable to true, but that did nothing. also set toggleSwitch colours... nope so what am i missing?
oh, and this styleable? need the rounded pills for the design spec
props.cells.allowEditOn : single-click.
That will "open" the cell for edit and then you have to toggle the switch with a second click.
There's a way to pass the first click though. Someone will post it.
okay. yeah. i need that single-click to be a one shot deal. the guys we build for are not the sharpest knife in the drawer UI-wise. but that method chain will be very useful in the other parts of the UI. thank you!
hm. no love so far. i can get the toggle to flip, but as soon as i select a different row, it reverts to true.
in more news, i found that removing all the set columns allows the table to automatically build columns based on the dataset, which is fantastic because that was going to be my next question... except that i no longer can set the display to toggle. so i'm really hitting a brick wall here: can't set toggle, can't style toggle, can't actually USE toggle.
what is the best-practice for this scenario? we're pulling flags from a datasets which have variable number of columns of flags. i need to edit those flags and save the changes. i thought this might be straightforward, but i'm rather surprised it isn't. even the default checkbox doesn't work.
You'll find that that won't get you far. You need to set the field property before basic functions like header title, sorting, filtering and others will work. It's not that hard to script though if you get to grips with basic Python scripting and how to set dictionary values.
The binding to the database is one-way only. It won't write back.
To write back to the database you need to write some scripts and create the queries, preferrably using the system.db.runPrepUpdate() functions. It seems like a lot of work initially but that's because you're working with a database and not a spreadsheet.
i'm actually just working with datasets saved to the user tag. does that make any difference? no database is being used in this case: no SQL queries, just dataset references.
i know Python fairly well. still my biggest hurdle is being able to 'see' the output. i'm used to dumping contents to the console, seeing what i'm working with, and then setting up the exact functions i'm needing to get the data i want. for example, this script/dataset i'm working with puts square brackets around 2/3rds of the fields and has left most of the keys in the output. i don't know if that's representational or if that's the actual strings held in the dataset.
@jlandwerlen gave me some excellent advice on setting up logging, but that's a trip to the Gateway logging interface every damn time i want something simple. this feels lugubrious at best... and i think @nminchin hit it on the head: "it's always hard work".
as for the toggles themselves, i followed your post and it just generates this error:
Error running action 'component.onRowClick' on ian_development/ian_user_table@D/root/Table:
Traceback (most recent call last): File "<function:runAction>", line 9, in runAction TypeError:
'com.inductiveautomation.ignition.common.BasicDataset' object is unsubscriptable
and the Property Editor pane tells me that 'addtional properties aren't allowed'.
i am too new to understand what the heck that means. this should be a simple thing. it's a toggle for heaven's sake! how does it not have any useful base functionality? *sigh* whining aside, please help me understand how this should work.
The same principle applies, mostly. The dataset you're updating in your Perspective session is a different object in memory than the dataset on the tag. You should be writing your updated dataset back to the tag and allowing your binding to retrieve that into the Perspective session.
system.perspective.print will send logs from Perspective to the Designer console. It has to be 'lugubrious' because of the split-brain execution model of Perspective; web browsers can't run Python/Jython, so all of your code is executing on the gateway. To avoid even weirder problems, the same applies to Perspective sessions in the Designer.
Datasets work "natively" in Perspective, but are different from JSON arrays of JSON objects. Crucially, datasets are not mutable, while JSON structures are. So that's Python telling you that someDataset[someColumn] is not a valid reference. You need to either A: translate your table's data from a dataset to a properly formatted JSON array, or B: translate your Python code to use system.dataset.setValue, which returns a new dataset you'd have to write back to the tag (again, different objects in memory).
This is just the property editor trying to tell you "don't add random elements to the defined component.props structure and expect them to work". You can do it - I don't think we have any code anywhere that will overwrite them (outside of bindings/scripts operating on higher levels) but it's not good practice; best practice is to house your random custom properties in component.custom
okay. this is a lot to digest. as you can probably tell, i am getting a tad frustrated. the dataset /pyDataset thing is tripping me up: the one is immutable, the other is. and i'm not finding what i need to get these toggles to work as expected by our design spec. it seems such a simple thing: flip a few toggles which changes the bits so i can store changed table. this seems to either be an outlier question or nobody really knows how to make the toggles work properly in this scenario. there has to be a way.
i hope i can at least style them so they match the design spec...
No, neither is mutable. That is why all of the system.dataset.* methods return new datasets.
Note, as JSON object is neither a Dataset nor a PyDataset.
To get this to work, when the Cell is committed you must write that back to the data source backing the table, otherwise, when the table refreshes it's binding for any reason the data in your table will be overwritten by the original data.
So in order to best help you, can you show how you are getting the data from your tag into your table? Is it a binding? Is that binding marked as bi-directional? Is it some other method?
i've gone through that page a few times now. i just have to tap out on this and admit defeat. i'll have to circle around some other time. this is taking up to much time for what should be a stupidly simple thing.
Right click the view in the project browser and hit 'Export'.
Or hold down shift and right click and 'Copy JSON' to export just the 'raw' JSON encoded structure of the view, with none of the other trappings of an Ignition project resource.
but then again, I don't do it often and always forget where I've done it before
