I have a named query which generates a dataset to a Perspective table.
The named query uses some date parameters which are configured as custom properties on the Perspective View. Specifically endDate and startDate.
These do not change their .value, but the .timestamp is changing constantly due to the fact they are bound to the realtime equivilants, executing a now(10000) expression.
This results in the named query being triggered every 10000ms, because the custom properties are changing their timestamps. This is extremely annoying. But i can see why it could be necessary.
However my problem is now that i can’t seem to detect a “REAL VALUE” change on the dataset.
I’ve put a valueChanged script on it, and print out the currentValue and previousValue of the data, and even though i thought the .value of the dataset shouldn’t change, a simple:
if currentValue.value != previousValue.value:
print "Something changed"
is always evaluating.
Is this a bug, or do we need to write comprehensive checks to ensure that the data in the dataset has actually changed? Such as comparing first and last values or something…
Probably just that the comparison doesn’t work exactly the way you might think when comparing two objects.
Perhaps try this:
from com.inductiveautomation.ignition.common.util import DatasetTestUtils
if not DatasetTestUtils.equals(currentValue.value,previousValue.value):
print "Something changed"
This is a case where I would use objectScript (from my free Simulation Aids module) in bindings for your date/time values. Its state dictionary can hold the prior datetime delivered and keep returning IT instead of the new one if they are equal. That would keep your named query from re-triggering.
Thank you both for the suggestions, I will give those a try.
objectScript functionality sounds great, I’d definitely rather have the binding not trigger the named query all the time, but i’ll need to run the idea of a 3rd party module through the client first.
