I'm trying to pass a literal boolean value to a popup view, but it appears that the parameters input isn't using Ignition's Expression language. Here's the error message I get:
Subcode: Error_ExpressionEval
'if' function expected a boolean or numeric first argument, but got a class java.lang.String
I get this error when I enter False or 0. It appears to just pass it as a string, even though the parameter is a boolean. My first thought is to create an AlwaysFalse custom property or just switch the if-statement to if({view.params.isReject} = 'True', ..., but that isn't exactly intuitive. Is there a better way of going about this?
Popup View Parameters
Main View Button Action Config
Popup View Error-Throwing Expression
I'm using Ignition v8.1.17 (b2022051210). If this functionality has changed in any more recent update, I could upgrade instead.
In python the bools are capitalized. Elsewhere they are not capitalized. When you pass your boolean value, it should be false or true rather than False or True
1 Like
use this:
'Enter Qty '
+ if(toBoolean({view.params.isReject}),'Rejected','Passed'
)
That should work. The value is being passed as a string so it needs to be converted.
It doesn't have to be passed as a string. Literal booleans do exist and should be used where appropriate, without having to resort to casting them.
1 Like
This seems like the source of the problem. I would bet that the parameter config is going to coerce whatever you pass here into a string, so whether you specify True or true in that text field, it's going to be passed into the popup as "True" or "true".
1 Like
One more reason to use system.perspective.openPopup :X
1 Like
So if I just ran it as a script, I assume I can avoid the string coercion issue.
@PGriffith I've tested it, and yes, the capitalization doesn't matter. It appears to be a string with {bracket} notated inserts rather than an actual expression. Should I create a suggestion on the Features and Ideas site?
Curly braces means it's trying to evaluate whatever set in the config dialog as a property reference. This seems to be working as intended. For more dynamic variable passthrough, I think the script is fine.
I agree. But I made this post because I expected it to be the Expression language (or at least something with types), not a simple property reference coerced to a string.
After further testing, I've realized that the property reference happens once; it's not a live connection. If the property referenced in the parameter changes, then nothing happens in the popup. This would also imply that if the Expression language were to be implemented here, that would be a breaking change, because some projects may rely on a copy of that referenced property to be saved when passed into the new view. I think this means that popup view parameters were designed to be static after initialization.
After further further testing, I've realized that direct property references do in fact respect the type of the property they're referencing. I created an alwaysTrue custom property and passed that in to the view, and that was parsed as a boolean. So, the issue that remains is the inability to insert boolean or numerical literals into a popup parameter. I think this is a reasonable feature add, so I'll post a summary on the Features and Ideas site.
Thanks all for your help!
