Correct. Or, there is at least no shutdownEvent emitting errors.
Read the stack trace.
Error running session.onShutdown(session):
"session.onShutdown(session)" means that you have a Session Shutdown Event configured, and that Event is failing.
This is a separate issue which I will need more information to help resolve. Hopefully your own examination will reveal the issue. Sometimes you'll see similar issues if you have bindings which circle back on themselves and essentially create an infinite loop.
You need to go to the location you placed the binding and remove it. The issue you're seeing where you attempt to remove the data param could be caused if something in your View is creating that data array. Could you verify nothing is creating that property as part of a transform or propertyChange script?
The view.json is the source of truth for bindings and transforms.
What you could do is this:
Double-click your machine home card View node in the Project browser.
Hold Shift and then right-click the View node.
Select "Copy JSON".
Paste the contents of your clipboard into a text editor.
Save this file somewhere safe so that you can come back to it if something goes terribly wrong.
Duplicate the file and open the duplicate in the text editor.
Very carefully, remove the data array from the json.
I think the issue I am having is related to renaming a view param while it has a binding on it.
I have lots of screens with an input binding. And that is the param for an output SQL binding. This has been effective for me. However when it comes time to add something to it or rename it. Seems to be the issue. Now I am setting it up as input param and output custom property. And not seeing these issues. I am on 8.0.6
This was one of them. Before, I went through and fixed them all. I think that it has to do with renaming a persistent param. Like I said I was using the params incorrectly. As I understand. So maybe it’s expected. I was just following up. But, this JSON file was the one in the most recent video. I grabbed before I fixed it.
Okay, I’ve fixed the View in question, and here are a few notes about what I found:
The in param is bound to a Named Query where one of the parameters is another parameter. Don’t do this. The in param should be a custom property instead. “Inbound” params don’t allow for bindings, but we can’t stop users from configuring the param as an “outbound” param with a binding and then swapping the direction, which it looks like you’ve done here.
The param configs were in place, but the actual param definitions were missing, which can exist in older builds but which we haven’t seen in a long while. In what Version was this View originally made?
You have a View onStartup script which is setting most of the Params. Don’t do this. Inbound params which are written to run the risk of never displaying/representing values passed into them if you are writing values into them.
Recommendations (what I did):
ONLY pass the part param into this View.
Create wt, rev, in, and size custom properties.
Bind in to a Named Query where part is the parameter.
Bind wt, rev, and size to the in property, OR just make the in property the ONLY custom property and bind relevant fields against the necessary values (I would recommend switching the Named Query return type to json if going this route).
Remove all instances of property change scripts from the View. view.json (11.4 KB)
