Arrayfilter( function gives "Runtime error in call( procedure" message

This statement works fine:

arrayfilter a1,diff,sep,?(arraysearch(a2,import(),1,sep)>0,"",import())

but this gives a “Runtime error in call( procedure” message:

diff = arrayfilter(a1, sep, {?(arraysearch(a2,import(),1,sep)>0,"",import())})

I’ve had this problem before but this time I’ve quoted the formula and it still fails. What am I doing wrong?

I just ran this code in Pan 6 and Pan X which produced the expected results without any error:

local a1,a2,sep,diff
diff=""
sep=","
a1="blue,black,pink,green"
a2="red,orange,blue,pink"
arrayfilter a1,diff,sep,?(arraysearch(a2,import(),1,sep)>0,"",import())
message arraystrip(diff,",")

Output is “black,green”.

Yes, because that’s my first statement which I said works fine. Try the second one.

And you’ll find that using

arraydifference a1,a2,sep,diff

gives exactly the same result.

I didn’t read your first post correctly. Yes the arrayfilter( function version gives a runtime error for the arraysearch( formula in Pan6 but not in PanX. The arrayfilter and arraydifference statements work in both Panorama versions that I tested.

This is a limitation of the way the arrayfilter( function is implemented in Panorama 6. It’s a custom function. Its formula is a call( function that calls a procedure. The procedure builds an arrayfilter statement from the parameters provided, and then uses Execute to execute it. Local variables in your procedure are not in scope within the Execute. I’m pretty confident that your a2 variable is a local variable and the error, if call( could give you a meaningful error message, would be “Field or variable does not exist: a2”.

Fortunately, Panorama X doesn’t do it that way.

Will the problem be solved by declaring a2 as a global or are there other, hidden issues?

Declaring a2 as a global will work. Declaring it as a fileglobal will work if the file that was active when you declared the variable is still active when you use it, and if the file isn’t still active, you can use grabfilevariable( to get its value .

If you have the option of using the statement instead of the function, that would be the ideal choice.

Why is that? I actually want the function because I need to use it in a formulafill statement but, given that the function just calls the statement, I’m interested to know your reasoning.

It’s the internal mechanism of how a function calls a statement that causes the issue with local variables.

Note, I did say “if you have the option.” If you are using it in a formulafill, you don’t have the option.

My reasoning is this. In the end it’s going to be the statement that runs anyway, so why incur the extra overhead of having a procedure build it, compile it, and execute it, when you could have just written the statement in the first place. I don’t like the fact that I can’t use local variables in the quoted formula. I don’t like the fact that “Runtime error in call( procedure” is the only error message I can get when something goes wrong.

The fact that the function is available when only a function will do is great, but if it’s a case of heads I’ll use the statement, tails the function, I’m getting out the two headed coin.