i assume there’s a perhaps over-optimistic check to prevent use of tags() in an iteration function (because attempting that gives the same results)
Not a check, but simply not possible. tags() needs access to the context, and that has to be stripped for iteration.
1 Like
should/does this implicitly apply to the transformExpr arg of transform()? (not technically “iteration”)
No, it doesn't.
should this return null? (the equivalent nested transform binding doesn’t)
transform(
'',
forEach( // <<< this breaks tags()
asList(''),
tags(asList(value()))[0][1]
)
)
this works fine
transform(
'',
// forEach(
// asList(''),
tags(asList(value()))[0][1]
// )
)
as does this:
Yes, you have tag() in an iterator expression. No can do, as mentioned above.
1 Like
Hey @pturmel, would you consider adding an expression function to this module to return a UUID string?
Hmm. That's a good idea. I've put it on my to-do list.
2 Likes
I added one to @PGriffith’s ignition-extensions a while ago, but it hasn’t been published since it was added 
1 Like
This is awesome Phil, thanks! I had setting up a long lived queue on my to do list, I'm glad I procrastinated!
One feature request if it's not too much to ask - additional parameters similar to the initialChange and previousValue on a normal tag change script. The thing I'm fighting now is a gateway restart or OPC connection restored being processed as a value change. Being able to filter out entries that are initialChange or have a Not-Good previous value would be great.
It is too much to ask. Those don't exist in the tag actor pipeline. If you need this, your bulk script must maintain a cache of tag paths & values it is told to handle, and treat cache misses as the "initial change" indicator.
I figured it might be something that's a ton of work. I'll work out a way to track things myself.
Thanks Phil!
Hey Phil,
Have you considered adding a slice() expression that would allow for slicing a list similar to the python slicing operations?
I ask, because I think that:
slice({path.to.list},startIndex,endIndex)
would perhaps be a bit cleaner than:
where( {path.to.list}, idx() >= startIndex, idx() < endIndex)
I don't know. One function call versus one function call. 
Not going to be a high priority. I'm hoping Paul includes it in the [] operator....
Slicing might be an issue with our parser, but I'm not against it in principle. No time soon.
2 Likes