For some reason, Ignition does not like this code:
def valueChanged(self, previousValue, currentValue, origin, missedEvents):
if currentValue and currentValue.value:
if self.params.material_id > 0:
self.custom.mat1 = self.params.material_id
else:
message = 'chg_lid_action'
system.perspective.sendMessage(message)
No red indicators visible in the editor.
This code has the same problem:
def valueChanged(self, previousValue, currentValue, origin, missedEvents):
if currentValue and currentValue.value:
message = 'chg_lid_action'
system.perspective.sendMessage(message)
Both are executed against view.params.properties, e.g. pos_1 and action, respectively.
Both have incoming values from a Popup, via a message handler. Almost every time I save the project, one or the other produces the error that the code could not be compiled: null pointer exception.
I know the second change script runs, because I can see the results in the browser.
Thoughts on what to look at?
If, the null pointer is pointing to the currentValue, why would it consider that object in this case? Do I need to include previousValue as well?
View parameters don't change. They're read once when the view is loaded and that's it!
That might be enough to get you started on finding a fix or a correct way to achieve your goal.
A few other things strike me as odd:
Why check currentValue and currentValue.value? Surely checking the second proves the first is true as well?
if self.params.material_id > 0:. Do you need the > 0?
system.perspective.sendMessage requires a payload. Use {} if there is nothing to send. Ignition might be tolerating it for now but it could break in a later version. system.perspective.sendMessage(messageType, payload, [scope], [sessionId], [pageId]) system.perspective.sendMessage - Ignition User Manual 8.1 - Ignition Documentation
The first checks the currentValue object isn't None, the second checks its value.
I actually always write the condition I looking for explicitly. There have been too many times I've relied on Python's implicit comparison (or whatever it's called) and it's resulted in failed code runs under certain circumstances
If you remove the first test you will get a "None type has no property 'currentValue'". Python short circuits if conditions which is why it doesn't fail with the two conditions
Technically this is correct, however, currentValue should never be None. previousValue will be none on initial change, but if you’re not using it no need to check.
So, passing values back to an already loaded view, via the parameters, is not good practice, even with embedded views?
If so, that means I need to use more message handlers to do the work that needs to be done.
Good question!
I would think that the Embedded View component is designed to retrigger the view on parameter change. I've just tried it out in Designer and it does work.
If a message handler changes the value of a parameter, on an embedded view, does that qualify as an action that would trigger the change script on the parameter?
You'll need to closely examine that error message and the line of code it indicates is the problem. See if there's a squiggly red mark in code editor in the right margin.
You can't change a view's parameter from within the view. They're read-only.
If you change the view parameter on an Embedded View parameter by a message handler (on the Embedded View component - not in the view being embedded) then it should work.
Edit: This is a different one that popped up right after I added and saved it, but same error.
Edit #2:
Restarted Designer, neither params (with the below change script and the one mentioned in the script) exist. All changes are saved regularly, and now both are gone. However, the embedded view still "sees" the params because I can select them from the list (props.params).
I think it's because I made them non-persistent. I was thinking persistence pertained to the value the param held, not the param itself.
Another edit:
I created the params again, and the script magically appeared.
Details of error:
java.lang.NullPointerException
com.inductiveautomation.ignition.common.GenericTransferrableException
Ignition v8.1.33 (b2023101913)
Java: Azul Systems, Inc. 17.0.8
That's not a compile error. That's an execution error. Unfortunately, you have an abbreviated traceback. You won't get more information unless you alter your ignition.conf to include an additional option of -XX:-OmitStackTraceInFastThrow to avoid the abbreviation. (You'll have to restart the gateway for that to take effect. Then you can get a complete error report.)