just updated to ignition version 8.1.22 and i've noticed that some of my components in perspective aren't loading properly because it cannot find the bindings.
in previous versions, if you were in designer and selected a row in a table, when you saved the project that row would be selected by default when the pages loaded.
in the case i have, i have a table with 200 rows which allows you to select a row, and then some of the selected data is plotted in a xy chart next to the table.
what i had prior to the update was row 1 selected, with the selected data from row 1 showing in the xy chart
after the update the chart shows an overlay error until you select a row. so i have a component that NEVER LOADS properly.
has anyone noticed this? was this intentional by ignition?
Possibly a change in the default of persistence of the rows themselves? If they don't persist, the component will definitely delete the selection on startup, as the selected row(s) must exist.
When a component starts up, its bindings haven't run yet. So if the query binding isn't set to persist the rows, they won't be there at component startup. Check your query binding. Also check that the data property itself is set to persist. I'm not sure what might have changed, but defaults for persistence would be my first bet. (You don't say what version you came from.)
i changed nothing between this component working properly and it not loading based on a lack of data in the "selected" property. the only change was the ignition version. i'll find out what our previous version was, i didn't do the update.
it's not using a query binding, it's using a dataset tag. none of this data is being retrieved from a database it's stored in a tag in the tag provider.
do i want to set anything to persist when i'm using an indirect binding? this component is in an embedded object so i'm passing parameter values to it.
That's still a binding. Bindings don't run instantly. I don't know if such bindings even have an option for persistence. I agree that something changed, and it has messed you up, but I don't know what that might have been, and I'm trying to help you resolve your situation. Even if an unintentional change on IA's part, that you can expect to be reverted (in some future version), I presume you want it to work in the meantime?
If you are just going to complain about it, you can contact IA support and do it with them. I'm a non-IA volunteer here.
The indirection is a possibility. Check that the source of the string used for indirection is persistent. If the dataset is invalid due to indirection even briefly (too fast to see, even), the component may kill the selection.
Consider binding the selection to a constant expression. Or perhaps, to a runScript expression that delivers a constant, but include polling=0, and the .data property as a throw-away that exists solely to ensure the binding order.
the dataset is static and never changes. it's just a list of tagpaths. so if you click on row 5, it populates the selection data with a tag path. this tag is not subject to being written or changing under any circumstances, it's really just an address book.
i don't think i can bind to the selected data property as it's dependent on the table, no?
i tried a few things. i bound the "selected row" property to a fixed value of zero, but that didn't work
i created a custom property array that had all the same elements as the selected data would have, and bound selected data to that and that didn't work either.
it seems to me that on initial component load, the selected row is null, so the selected data is null, even if these properties have bound values to them.
Just to clarify, when Phil mentioned "persisting" the binding, he meant right clicking on the binding and selecting "persistent" (from memory, could be slightly different wording). This means the value of the binding as it is in the designer, will be saved with the View. If this is off, then the value is not saved with the View and hence will not exist (null) on initial load until the binding runs.
There was a bug with the selection which I don't know if it was fixed or not, but seems related. The bug was that when you selected a row, deleted that row from the props.data, the same index would still be selected (expected) but the selection data would still be the old deleted row's data; the values were not updated. Same thing for adding rows before the index as well. If this was fixed, then I'd suspect this might be the reason it broke for you. Setting the props.data to persistent though I would think would resolve it, but not sure
oh interesting. persistent was not selected on props.data, selecting it seems to have resolved the issue. it looks like mr turmel mentioned that earlier, but i understood his "data" to be the selection.data property, and not the primary data property. that's my mistake.
thank you all for your help. this wasn't a make or break as the component worked fine after the user interacted with the table, but it's a much better look to have it working on initial load.
i wonder if IA changed the default from persistent to non in an update. our previous version was 8.1.07
