Navigating Between Displays in PI ActiveView: Challenges and Workarounds

When developing dashboard systems with OSIsoft’s PI ProcessBook and PI ActiveView, one common requirement is seamless navigation between multiple displays—ideally passing context, such as a breadcrumb trail, from one display to the next. However, the differences between ProcessBook (the desktop client) and ActiveView (the web-enabled viewer) can present some tricky challenges for engineers and developers.

The Challenge: Contextual Navigation in ActiveView

In PI ProcessBook, it’s possible to open new displays, pass values or variables between them using VBA, and manage multiple display windows. This lends itself nicely to building more complex navigation schemes. But in ActiveView, there are critical constraints:

• Single Display Limitation: ActiveView only allows one display to be open at a time per user session.
• Communication Between Displays: There is no built-in, stateful mechanism for passing information (such as navigation context or breadcrumbs) from one display to another within the ActiveView environment.

A common workflow attempted is using VBA to open a new display (with Application.Displays.Open) and then close the current display, while attempting to pass some state or variable into the new one.

The Pitfalls

• Blank Displays: Some users report that after opening and closing displays using VBA in ActiveView, subsequent attempts to open displays result in a blank or grey window, even though the same code works fine in ProcessBook.
• File Paths & SharePoint: When running in ActiveView (especially from SharePoint or web portal environments), trying to access the display’s path in VBA may return unexpected results, such as local temporary directories rather than the shared server path.

Workarounds and Alternative Approaches

Given these limitations, several workarounds and best practices can help bridge the gap:

1. Session Log Files

One approach is to store navigation state externally—for example, writing the breadcrumb trail to a temporary session log file (e.g., in the user’s profile directory). Each display, upon opening, reads from this session file to determine navigation context.

Pros:

• Simple and doesn’t require modification to the ActiveView control itself
• Can store other session data, such as user preferences or last visited locations

Cons:

• File system access may be restricted in some environments
• Not robust for multi-user or concurrent session scenarios
• Not easily portable or scalable for larger dashboard solutions

2. URL Parameters and Display Naming

If your ActiveView displays are served via URLs (e.g., SharePoint or a web portal), consider encoding navigation context directly into the URL parameters. For example, http://myserver/ActiveView/display.pdi?trail=Area1>Unit2>ReportX. Each PDI can parse the URL (via VBA or .NET add-in) to retrieve the context.

Caveats:

• Requires some web scripting knowledge
• Not every environment exposes URL parameters to VBA or in-display scripts

3. Centralized State via .NET Add-in (Advanced)

If you’re generating and managing displays via a custom .NET add-in, you could maintain navigation context within your add-in and interact with the ActiveView control(s) programmatically. For complex dashboards, multiple ActiveView controls can be instantiated in your application UI and swapped for visibility.

Note: This approach is only viable if you have control over the hosting application and are using ActiveView as a component—not simply from the web browser.

4. Simplified Navigation Model

Rather than passing context between displays, consider designing your displays to be more self-contained, including a navigation menu or panel that allows users to jump anywhere in the dashboard hierarchy, reducing the need for breadcrumb tracking.

Recommendations

• Test Extensively in ActiveView: Some techniques that work in ProcessBook may not translate to ActiveView. Always validate with your actual deployment platform.
• Document Known Issues and User Guidance: If blank displays occur after certain navigation actions, document these limitations for your end-users and propose preferred navigation methods.
• Consider Modernizing: PI ProcessBook and ActiveView are legacy technologies. Evaluate if PI Vision or custom web-based dashboards (with AF SDK or PI Web API) may offer a more flexible and modern solution for your requirements.

Conclusion

Implementing sophisticated navigation and context-passing in PI ActiveView requires workarounds due to platform limitations. Solutions such as temporary state files, URL parameters, or centralized .NET logic can help—each with pros and cons. Understanding these constraints up front will help you design effective dashboards and guide your users appropriately. For large or strategic dashboard projects, consider leveraging PI Vision or developing custom web dashboards for a more robust experience.

Have you solved navigation challenges in ActiveView? Share your tips in the comments!