Perspective: Property change script on json returns QualifiedValues for all items

Not sure if this is intended or not, but I have an array property that contains objects (json) with two keys. I have a change script on it and I’m using currentValue.value to get the json as py objects, however i’ve found that in order to see the value of items on the json, I need to use .value after each subscriptable access. It seems that all items within the json are QVs as well

E.g.

image

to read options[0]['value'] I need to use:
currentValue.value[0].value['value'].value
So many .values!
Shouldn’t the QV only apply to the outer-most value? e.g. just the currentValue?

Which version are you on? From what I remember, there were a couple bugs around this kind of thing late in 8.0; I think 8.0.17 is supposed to have them fixed, but I’m not 100%.

I’m on 8.1.0 lts

Is there a better way to do this now? I just dealt with a mess of .values in a change script that would be nice to avoid.

Looks like this is still hanging around in 8.1.28 or any chance there was a regression that brought this back to life? Definitely an annoying amount of value references to access the value you're after... Would it even be possible at this point to get rid of this behavior since I'm assuming so many deployments are now expecting all the sub objects to be QVs in scripts and would break on upgrade if this was changed?

I would rather it fixed and have minor breaking changes to fix than have this to deal with though. So long as it's documented that it has changed. I haven't noticed this at all though tbh, although I'm not on 28 anywhere

Anybody got a self contained view/project that demonstrates the problem?
If it does require breaking changes, 8.3.0 is the time to make them.

I am able to reproduce with the table component and the default example data that is packaged with the table component by utilizing a change script on the data property (8.1.28). No changes to the component/data beyond adding the change script and editing a value in the data property to trigger the change script. If you're not seeing the same behavior on your end, let me know and I can send a self contained view.

2 Likes

Thanks - that got me to the root of the issue, which is a code path that should've been fixed for 8.0.0 :grimacing:

I've made a strong suggestion to the Perspective team to get it fixed in 8.3.0.

1 Like

Is this why all my new iterator functions in Simulation Aids needed helpers to unqualify everything they encountered?

Possibly? It's a static method in com.inductiveautomation.perspective.gateway.binding.BindingUtils that needs to be called. I'm not diving into the actual logic of where the QV-containing-array-of-QVs behavior is originating. Some other time.

Yeah, that. And some friends of his.

I unqualify them with this:

    protected static class QualifiedArrayIterator implements Iterator<Object> {
        protected final Object[] source;
        protected int nextIdx = 0;

        protected QualifiedArrayIterator(Object[] source) {
            this.source = source;
        }

        @Override
        public boolean hasNext() {
            return nextIdx < source.length;
        }

        @Override
        public Object next() {
            Object retv = source[nextIdx++];
            if (retv instanceof QualifiedValue)
                retv = ((QualifiedValue) retv).getValue();
            return retv;
        }
    }