Summing Ignition Perspective Table Columns After Filtering

What is the screen telling you when the total won't follow the dropdowns?

The operator picks a status or part number from a dropdown. The table rows change, but the pallet-weight total either shows the grand total or keeps the value from the previous selection. The Perspective table has no built-in column footer or aggregate for this case. You have to build the total yourself, and it only updates if its binding subscribes to something that changes when the filter changes.

Perspective bindings are subscription-driven. A property binding re-evaluates only when the property it points at changes. A script transform runs only when its binding's input changes. If the transform reads a dropdown with self.getSibling(...), that read does not create a subscription. The tag is right; the binding is wrong. The checks below find which of three architectures you have and route you to the matching fix.

Check 1: Is the table's built-in filter doing the filtering?

Reading: In the Designer Property Editor, look at the table's filter properties while you type in the table's own filter box in preview.

• Built-in filter in use: The table publishes the filtered rows at filter.results.data. Bind your total to that path and stop here.
• Filtering is done with external dropdowns or text inputs: filter.results.data is not populated by your logic. Go to Check 2.

Check 2: Does props.data change when a dropdown changes?

Reading: Open the table's props.data in the Property Editor during preview. Change a dropdown and watch whether the dataset row count changes.

For the first row, an expression on the total label is enough. Adjust the component path and column name to your view:

// Total weight
sum({../Table.props.data}, "PalletWeight")

// Record count
len({../Table.props.data})

Check 3: Should the filter live in SQL or in the view?

Two configurations both work. Choose based on data volume and how many filters you expect to add.

Prefer the in-view option for operator screens. The common failure in that design is a custom property bound only to props.data, with a transform that filters by reading dropdown values inside the script. When a dropdown changes, props.data does not change, so the transform never re-runs.

A working pattern is to send a message on each dropdown or text-input change and call refreshBinding on the custom property. That works, but every new input needs its own message call. A cleaner fix is to put every filter input into the binding itself, so the subscription does the work.

Which pitfalls keep coming back?

How do you build the filtered dataset and verify the total?

1. Leave the SQL binding that returns the full dataset where it is. Move it to a custom property on the table, for example custom.rawData.
2. Create a second custom property, custom.filteredData. Give it an expression structure binding with one key per input: data → {this.custom.rawData}, status → the status dropdown's props.value, part → the part-number dropdown's props.value. Any change to any key re-runs the transform.
3. Add a script transform to custom.filteredData. The column names below are examples; match them to your query.

   def transform(self, value, quality, timestamp):
       ds = value['data']
       status = value['status']
       part = value['part']
       headers = list(ds.getColumnNames())
       rows = []
       for r in range(ds.getRowCount()):
           if status and ds.getValueAt(r, 'Status') != status:
               continue
           if part and ds.getValueAt(r, 'PartNumber') != part:
               continue
           rows.append([ds.getValueAt(r, c) for c in range(ds.getColumnCount())])
       return system.dataset.toDataSet(headers, rows)

4. Bind the table's props.data to {this.custom.filteredData}. The table now shows exactly what the total sums.
5. Bind the total label to sum({../Table.custom.filteredData}, "PalletWeight") and the count label to len({../Table.custom.filteredData}). If the column can contain nulls, compute the sum in a transform that skips them.
6. To add a future filter, add one key to the expression structure and one if test to the transform. No message handlers need updating.
7. If you keep the message-based design instead, have each input's onChange event send a message. In the table's message handler, call self.refreshBinding('custom.filteredData'). Confirm the message scope reaches the table.

Verification: Clear all dropdowns and confirm the total equals a manual SELECT SUM(...) of the unfiltered query. Select one status value and confirm the count label matches the row count shown in the table. Then change the part-number dropdown without touching status, and confirm both labels update on the first change, not the second. Finally, run the same SUM in the database with both filter values in the WHERE clause. The screen total must match it to the last decimal the column carries.

FAQ