There’s a bug in the configureCell() extension function on the Power Table component in Vision.
I tested on 8.1 and 7.9, both of which have the bug.
When selecting a row from a power table, configureCell() does not execute for all cells. Instead, the cells it executes on depend on the index of the selected row. There appears to be a logical bug in how the cells are looped over.
To reproduce the bug:
Create a Power Table and populate it with 5 values in one column of data. The bug is present regardless of the number of columns or rows, but it’s easier to test with less data.
Set the Power Table’s configureCell() function to:
Run the component and select various rows. In the debugging console you’ll see that the rows being processed by configureCell() are not consistent and depend on the row selected in the UI.
No, configureCell is called any time the cell needs to be displayed or refreshed. Scrolling, selecting, and data updates can all trigger this call, and it will only be called as needed. Cells out of sight due to scrolling may not be called at all.
Rethink whatever you are trying to do in configureCell that doesn’t fit the display paradigm. Certainly do not attempt to change any state in the table there.
Thanks for the insight, however, what you are describing doesn’t reflect the actual behavior of the component.
It’s also not true that configureCell() “will only be called as needed”. If you actually test it, you’ll see that it executes when it isn’t necessary and the execution behavior is inconsistent depending on the row you select and which row was previously selected.
Yeah, well, it’s Swing underneath. The repaint operation is the primary driver, and “dirty” display rectangles can merge/overlap in odd ways. So, it should read “called as needed as determined by Swing”. If you are really curious, you can construct and log a fake java exception to see all of the call chains. Have fun.
Still not a bug (in Ignition). Attempting to do anything other that supplying display attributes for the requested cell is a recipe for grief.
The function is not running for the rows that are actually displayed, instead, it runs for all rows between the row you select and the row previously selected. This is a bug.
I think @pturmel’s explanation helps narrow down what’s happening. There appears to be a logical bug in determining which rows are displayed and therefore which need to be updated.
That usually means you are accessing stuff in configureCell that isn’t local to the component. Like system.* calls that go to the gateway. There should be custom properties on your table that pull in all ancillary data you need for display, so the configureCell event itself doesn’t have to go get it. (It is already there.)
If your performance craters when you run a remote client over a satellite connection or worldwide VPN, you’ve probably made this kind of mistake.
That’s good advice.
With the extra executions, we’ve seen performance issues on large tables even when executing simple logic that doesn’t rely on anything external to the table.
As Phil said, this is not an Ignition bug. You can easily demonstrate the same behavior in a standalone Swing project with a JideTable or JTable you create yourself; TableCellRenderer makes no guarantees about when it will be called, and the behavior of painting and repainting is non-trivial.
It is absolutely true that on very large tables, even the minimal overhead of calling into Jython is going to add up. You can minimize that as much as possible by using custom properties well, as Phil recommended, but there is a limit. In theory, I would expect a fully custom Java component (authored through the module SDK) to perform at the same rendering task than the power table, because it wouldn’t have the additional Jython overhead - but obviously that’s a tall order to set up.
Some tips for superior performance on events that get called (a lot) by Swing:
Move all use of class and def to a project script module.
Make all ancillary data needed available in custom properties. Preferably using asynchronous bindings (Tag bindings and Query bindings) or property bindings. If a script is needed to collect ancillary data, use system.util.invokeAsynchronous() to do the time-consuming part off the GUI thread.
Avoid loops. If a lookup will be needed, post-process the corresponding ancillary data into a Python dictionary, and cache it in the component’s Swing “client properties”. The fast path in the event would use d=self.getClientProperty(...) then d.get(someKey) to perform the lookup.
Move as much code as practical into a project script module.
