[Bug-11644] Gateway Receives Events For Missing Views

I was stepping through the process and watching the wrapper.log file this morning and I noticed something.
the “view missing” message does not hit the wrapper.log until I navigate away from my Main_Views/Navigation view to the Material_User/Log_On view.

The Log_On view Back Button does have an onClick event to take the users back to the Main_Views/Navigation view. This will also apply to other views to assist with the user navigation through the app…
Could I be getting this message because it is looking for a view to be present that has been sent to garbage collection (GC) or that is connected to a page that has been sent to GC?

Not likely - it would be a tremendous waste of computing resources to scan everything about a View and make sure it’s all going to work before we need to use it.

As there’s no adverse effects that seem to be stemming from this “missing view” I wouldn’t worry too much about it, but if you want to investigate further you could always provide some logging as a way to lock-down exactly what is happening and when.

While investigating this issue further, I’ve found that use of the system.perspective.navigate() method does not encounter the “missing view” issue.

I also encountered a different issue during the course of my investigation that is leading me to recommend that you switch to using the system.perspective.navigate() method, and that issue is that Script Actions don’t seem to be executing when paired with a Navigate Action.

1 Like

So would this be a temporary case of “either/or” usage or should this be resolved later in a future build?

Removing the Navigate event also helped resolve my label text not changing due to not updating from the session.custom.key.value

In the “User Log On” Button:
Emp_Role = ‘Operator’
self.session.custom.Emp_Role = Emp_Role

And in the “Back Button”:
Emp_Role = ‘’
self.session.custom.Emp_Role = Emp_Role

In the onStartup script for the Navigation View:
Emp_Role = ‘’
badge = ‘’
PW = ‘’
self.session.custom.Emp_Role = Emp_Role
self.session.custom.badge = badge
self.session.custom.PW = PW

Right, that’s because the Script Action was being ignored while using the Navigate Action. Moving to the Script Action with a navigation method will suffice as a workaround for now as the Script Action will now appropriately set the desired variables.

Side note:
If your Navigation View will always set the Session variables onStartup, you don’t need to set them before navigating to it, and you actually shouldn’t set them before navigating, as it will only make your personal debugging more difficult.

1 Like

Cody is doing a great job in helping identify and track these issues, so I don’t have anything to add there. Just wanted to say thanks for providing such helpful reports Brian. These really help us deliver a more polished product come final release.


This is something that we MUST fix; there should be no discernible difference in behavior regardless of which Action you choose to take.

So would there be a better method for making sure that the Emp_Role session variable is reset when users go back to the Navigation screen? I was assuming that if a standard user was done and a Quality Engineer needed to use the same device, I should reset that role variable to null and then allow the selection based on the log on. (BTW, that role is a database defined role with permissions, not an Ignition or gateway/project type role.)

Design in these situations is different for everyone, but if your desire is that whenever you visit this Navigation View those three variables are se to empty Strings, then your onStartup script is 100% correct.

I was only noting that the button which triggers navigation to your Navigation View is performing session.custom.Emp_Role = '', and then immediately when the new View comes into existence it performs the same action again.

If you ever modify the script for the button which does the navigation and say perform session.custom.Emp_Role = null, no null checks in scripts or bindings on the Navigation View will ever come back as True, because that null value has already been overridden with the empty String.

Ok, so that is a View onStartup event, not a Session onStartup event…

And then every time I navigate back to the Navigation view it will run the script as soon as it instantiates, correct?


Perspective Views do not “exist” unless they are open (which is why you can’t bind against properties in other Views), so a Session onStartup Script will fire once - as soon as your Session starts.

View onStartup Scripts will fire every time the View “loads”, whether this is through Navigation Actions, the perspective.navigate() method in a Script Action, or using your browser’s back button (remember, “pages” are still Views).

Any kind of ETA on this yet?

If you’re inquiring about ticket 11644 - which is the open ticket about a difference in behavior between using the navigate method and the navigate action - there is no ETA.

Sorry, to clarify: is there any ETA for the View onStartup and other View related events?

Additional question, the “script library [project].scriptName” executes on the gateway also for perspective and not on the client?

1 Like

View onStartup script Actions should be working right now - it’s just that certain other actions (like Barcode Scanning) don’t work in View onStartup Events. The fix for this won’t be in for quite some time (I’d be very surprised if it’s in before the holidays).

As for the script question, you are correct; NO scripts run in Perspective Sessions - ALL Perspective scripts execute on the Gateway.

Just to clarify, this does not apply to the event handler scripting, correct?

Any piece of scripting (ie, where you’re writing Python code) is going to execute on the gateway - including session event handling.

thanks for clearing that up :slight_smile: