I have a top dock that has toggleable components/containers with buttons by custom session property between an alarm summary component or a set of area-specific key indicators containers with various display objects in them. An “area index” is indicated by the title of the page in page configuration, set to integers that are meaningful for the areas. The visibilities of each area-specific key indicators containers are tied to the integer of the page title (and obviously being session-toggled to key indicators away from the alarm summary component). I tested this out by session and it appears to work. The Client will use either the Perspective Workstation app or a full-screen browser, so the page titles being non-descriptive numbers in a non full screen browser isn’t an issue.
Are there any pitfalls I’m overlooking with this approach? I had considered some other ways to do this, but couldn’t figure them out.
Also, as a follow-up, it would be nice if I could have a multi-monitor workstation client displays be toggleable independently. The area visibility currently works independently by display, but I just have one custom session property for the toggle. Would the following approach work:
Create a script in the library that gets the display #.
Create a custom view property on the top dock view (ex. view.custom.displayIndex) and run the “get display #” script via a binding on the property;
Create a second session property for toggle (ex. areaToggleDisplay1, areaToggleDisplay2); they will only have two monitors;
Create a second set of buttons with visibility bound to custom view property, interaction with session properties; and
Visibility of desired components based on view and session properties (i.e. if custom view property for display index is X, use areaToggleDisplayX session property)?
Apologize if this is an oversimplification, I don’t really know how to do the script or binding yet, but I read where someone else had done a similar, but slightly different concept.