Hello,
I have a question about bindings and copying them. Below I present my case.
Suppose I have several hundred different tag providers. In each provider I have a UDT structure of a dozen variables and an instance created in tags. I would like to create an array of structures from these different providers on the screen (so there will be several hundred of them).
From what I have deduced I need to do this manually and drag the structure from each provider onto the array element. This works well but the question is whether it can be done better somehow. That is, so that I don't drag each of these many structures to a table element? This seems to me to be the only sensible way but maybe someone has some advice because it's a lot of copying.
Another issue is when I need exactly the same array of structures for another screen. Copying it only copies the JSON i.e. the rigid values. This means that on another screen I have to copy it all again. In addition, I noticed that there is an option to copy bindings but I can't do it for the whole array but only for one element.
The data in each row of the structure is raw data and uses script transform to make it fully usable. For different screens these scripts are different and I guess there is no way to copy this with transform and then replace it in JSON.
I would use indirection, with a list of tagpaths instead of a list of UDT properties. Then have a subview or column view do the indirect bindings with that tagpath to get the values to display. This has multiple advantages:
No issues with bindings in the wrong places if you insert/delete array elements,
No issues with UDT parameters of slightly different definitions (Ugh--should never be used anyways),
Option to use bidirectional indirect bindings in the subview/column view to make elements editable.
{ Really, on that second one. Use Ignition UDTs to organize tags. Do not use Ignition UDTs in your UIs. They are an ugly, confining straightjacket. }
Very interesting. Take a look at this, I created a dataset with a tagpath put that in CUSTOM view and referenced those paths in the table by reading the structure using System.tag.readBlocking().
However, I have concerns about the performance of such a solution. I once tried this approach for reading other variables, and it turns out that for several hundred tags read this way, the execution time was more than a minute. The current solution directly referring to the structure in bindings anywhere in the data array table works in no time. I have concerns that this might slow down my table. Nevertheless, the approach turns out to be easy to set up and maintain.
Ewww! No. Use a subview or column view, and have that view use indirect tag binding. That will naturally keep your bindings updated without the overhead of repeated scripts.
What do you mean by subview or column view? Maybe it's simple but I don't really understand how to turn this tagpaths into tables with structures from tag providers?
Ok, I understand what you mean. This seems like a convenient approach. However, I have already created similar tables that displayed a subview in their cells and the problem was the long table loading time. For several hundred rows of the table, it caused a long loading when scrolling. Do you have any tips on this?
Tables have a 'virtualized' property, that might be causing the scrolling problem.
Try turning that off (I can see it's activated in your screenshot). be aware though that it might impact performances in other ways, ie: longer initial loading time of the table (disclaimer, I actually have no idea how it works behind the scenes and what the impacts might be). https://docs.inductiveautomation.com/display/DOC80/Perspective+-+Table
Yes, I tested this and it works differently Now the subviews load one at a time and when returning they do not expire without having to reload however in the column with the most extensive subviews it takes and takes for almost 500 rows.... So both solutions have their drawbacks, thank you for your advice
Consider reducing your expectations for a subview/column view. Your OP suggested you were reading a tag value for a tagpath in a column in your table. Consider using a simple view that does that one thing as a column (cell) view for that one tagpath column. Do all of the heavy stuff (outside the table) in a separate embedded view that binds to the tagpath of just one selected row.
