Hello, I think the title describes what I'm trying to accomplish. My client runs the same project across many devices. The issue they are seeing is that if userSessionA minimizes or switches to another browser tab during their session while looking at 'stationA', and userSessionB starts a new process on 'stationA', userSessionA is not updated when they switch back to their session. The correct view is shown, but the values within the template views are default values. Running system.perspective.refresh() updates the views. Best case is there's an event or some session var that captures whether or not the session has user 'focus', and I can fire a refresh based on that. Worse case, I'll add a button to refresh the session. Any ideas? Thanks in advance.
Where are the values coming from? Tag values? If displaying correct values relies on 100% uptime, there might be an architecture problem.
Otherwise:
Is there a way to auto refresh a perspective session
Is there some changing value that can be referenced in a session.custom property binding? If the two values (gateway 'last update' vs client 'last update') are out-of-sync, trigger a system.perspective.refresh()?
Thanks for the reply, Chris. I kept digging into this looking at how the views are set up architecturally. The screen in question has a couple embedded views in it that have the loading order prop set to 'with-parent'. This seemed ok per the user manual, but for science, I switched them to 'after-parent' and the view behaved as expected. Could this be due to the parent passing params to the view? One of the params send is the screen udt path for the embedded view. I can recreate the issue and the expected behavior just by changing that one prop. So, I'm thinking that fixes it, I just don't completely understand the why of it or why the screen udt path would be a param.
I can think of easier ways to pass in station specific vars. There have been many 'cooks in the kitchen' with this project. Anyway, thanks again.
If I understand correctly, this seems reasonable. Any time an embedded view (or popup) requires a dynamic tag path as an input parameter, I prefer to pass the tag path as a string (instead of a binding which passes the value of a tag or property) so that there's more flexibility to do something with that path within the view.
While 'after-parent' feels like the better choice, I would not expect this to cause the issue you're experiencing.
Can you share a more detailed example - one tag value that is not updating - from start to finish? e.g.:
- Parent View (named "View1") contains EmbeddedView object (named "EmbeddedView_0") with following properties:
- Path = "Views/Embedded/ViewA"
- Parameters:
- tagPath = "[default]Path/To/Tag"
- Views/Embedded/ViewA:
- Input Parameters:
- tagPath = null (populated at runtime)
- (Object with Specifics of Indirect Tag Binding)
- etc...
- Input Parameters:
Optionally, any screenshots that you feel might better-convey the setup might be useful.
I was incorrect, this particular embedded doesn't pass a tag path.
Parent View (StatusDisplay) contains EmbeddedView(ProcessStepsDisplay)
- currentStepNumber is a prop binding to the parent udt.
- steps is a prop binding to parent udt with a script transform that calls a function from the local library
Here are the details on that binding
templates/ProcessStepsDisplay
Input Params
The two change scripts seem to be manipulating the scroll index
Not sure if anything jumps out at you, but I appreciate the time. It seems to work now and the client is considering this resolved. Further investigation is going to be for my own curiosity/growth. Thank you.
Tips:
- Create a view custom variable,
sliderValue(or whatever), and add a bidirectional property binding between the slider'svalueproperty andview.custom.sliderValue. - Edit the Property Change Script: view params.firstIndex (shown in the last screengrab) to,
else:
view.custom.sliderValue = currentValue.value
The way you have it at the moment is 'brittle'. If you move the slider or wrap it in another or different container your application will break. Using the view.custom avoids all that family tree stuff and makes it much easier to manage and read.
+1 for usage of the word 'brittle' by @Transistor.
If information needs to be synced between clients, the tag database (preferably, reading directly from a logic controller) might be a better place to store the state of a system.