On the reported six-monitor Ignition client, multi-monitor behavior depends on which desktop owns a window and whether navigation is linked through a shared client tag. Popup placement, synchronized navigation, and unexpected windows after updates point to different parts of that desktop and navigation model; diagnose them separately before replacing the multi-monitor layout with separate clients.
Desktop context determines where windows open
Ignition multi-monitor support was added in 7.9. The reported setup used multiple desktops within a client, but several behaviors do not automatically follow the operator's visual expectation that an action belongs to the desktop where it was initiated. In particular, a popup can open on the main desktop unless its script explicitly obtains and uses the relevant desktop's window utilities.
For popup routing, the deciding quantity is not monitor number; it is the desktop context supplied to the window operation. The system.gui.desktop function provides desktop-specific WindowUtilities. Scripts that open windows or message boxes need to use the returned utilities rather than relying on the default operation to infer the originating desktop.
| Observed behavior | Mechanism or diagnostic lead | Where to check |
|---|---|---|
| Popup opens on the main desktop | The operation is not targeting the desktop where the user initiated it. | Popup script; system.gui.desktop result and WindowUtilities used by open-window or message-box calls. |
| Navigation on one desktop changes others | Navigation may be bidirectionally bound to a shared current-window client tag. | Project navigation bindings, especially System/Client/User/CurrentWindow. |
| Desktop returns to an unexpected window after update | Check the navigation binding and each desktop's launch window. Returning to the initially launched window was suggested as a possibility, not confirmed for this case. | Tab-strip bindings and behavior before and after an update. |
| Docked window ignores north/south or east/west preference | A known issue was reported for the behavior; the report provides no fix. | Reproduce the dock setting and record the exact Ignition version for support. |
Multi-monitor clients and separate clients solve different problems
The reported choices are to keep the multi-monitor feature and correct the project-level routing, or return to opening a separate client on each window. The first approach keeps the feature the operator wanted but requires scripts and navigation bindings to match the intended desktop behavior. The second is a valid fallback if the project requires independent navigation and the multi-monitor behavior cannot be made predictable; the report does not compare resource usage or establish that separate clients remove every issue.
| Approach | Fits when | Tradeoff |
|---|---|---|
| One client with multiple desktops | Operators need coordinated desktop support and the project can explicitly route popups and control navigation synchronization. | Desktop context and shared navigation bindings must be tested; the dock preference issue may remain. |
| Separate client per display/window | Each display needs independent window selection, or project scripts cannot reliably target the intended desktop. | It abandons the multi-monitor feature; the evidence does not specify client-management or runtime costs. |
Prefer the multi-monitor layout only after confirming that each desktop's launch window, popup routing, and navigation coupling match the operator workflow. Keep separate clients as a deliberate alternative when independence is the requirement, not as a presumed cure for every multi-monitor defect.
Shared CurrentWindow bindings explain synchronized navigation
Some template projects bind their navigation system bidirectionally to [System]Client/User/CurrentWindow. A window event on one desktop can then update the shared current-window value, which drives navigation on other desktops. This behavior is distinct from a tab strip that navigates locally on each desktop. Therefore, one desktop navigating all the others can be a consequence of the project's binding design rather than a failure of the tab strip itself.
Inspect the project's navigation structure before trying to suppress synchronization. Confirm whether the affected screens use the template-style bidirectional binding, whether tab-strip actions update the same shared value, and whether the desired operator behavior is synchronized navigation or independent screens. If the binding is the cause, change the project navigation design to stop coupling those desktops; do not treat popup routing changes as a fix for navigation propagation.
Popup scripts must target the initiating desktop
The main-desktop popup behavior requires a scripting change. The reported correction is to call system.gui.desktop, then use its returned WindowUtilities for window-opening, message-box, and similar operations. That returned utility object carries the desktop target; a call that continues to use the default utility path can keep opening on the main desktop.
- Locate each script that opens a popup, window, or message box from a multi-monitor desktop.
- Obtain the desktop-specific
WindowUtilitiesthroughsystem.gui.desktopin that script's execution context. - Change the relevant open-window, message-box, or equivalent operation to use the returned utilities.
- Test the action from each desktop, including an action launched from a secondary desktop, and confirm the popup appears on the intended desktop.
The evidence does not provide a function signature or a complete script, so use the function's documented arguments and return value for the installed Ignition version rather than copying an invented code sample. Test message boxes separately: a request to make their default behavior follow the calling desktop was raised, but the described correction is to explicitly use the desktop-specific utilities.
Dock preference and update behavior need separate diagnosis
The north/south or east/west docked-window preference was identified as a known issue in the reported discussion, with no developer fix stated. Treat it as a separate defect from script routing and shared navigation. Record the selected preference, the observed dock placement, the monitor layout, and the installed Ignition version so the behavior can be reproduced. Do not expect changes to CurrentWindow bindings or popup scripts to correct docking.
Unexpected main-window changes after pushing updates are not enough to identify a root cause. The reported diagnostic suggestion was that desktops might return to the windows they launched with, but that did not match the operator's experience. A bidirectional tab-strip binding was also considered as a possible contributor. Compare each desktop's displayed window immediately before and after the update, its launch window, and whether navigation or a binding value changes. Preserve the result as a reproducible case rather than labeling the update mechanism itself as the cause.
Verify each desktop independently before returning to service
Use a controlled test project state and change one behavior at a time. This separates desktop-specific routing from project-wide navigation coupling and prevents a successful popup fix from masking a remaining synchronization or docking problem.
- Record the installed Ignition version, monitor count, desktop launch windows, dock preference, and the exact action that reproduces each problem.
- Test navigation from the original or parent client, then from each desktop's tab strip. Note whether other desktops change and inspect the
[System]Client/User/CurrentWindowbinding when they do. - Test one popup and one message box from the main desktop and from a secondary desktop after changing the scripts to use the returned
WindowUtilities. - Push an update and record the window shown on every desktop before and after. Compare the result with the configured launch windows and any tab-strip binding changes.
- Test north/south and east/west docking independently, recording whether the selected preference is honored.
Accept the configuration only when popup placement matches the initiating desktop, navigation synchronization matches the intended workflow, and update behavior is repeatable. If the dock preference still fails, or the update test produces unexplained window changes, retain the reproduction details and isolate the affected behavior rather than combining several script or binding edits.
Frequently asked questions
Can I open a popup on the desktop where I clicked?
Use system.gui.desktop to obtain that desktop's WindowUtilities, then use the returned utilities for the window-opening or message-box operation. Test from both the main and secondary desktops.
Does Ignition synchronize navigation across desktops by default?
The reported synchronization occurred in projects whose navigation was bidirectionally bound to [System]Client/User/CurrentWindow. Inspect the project bindings; tab-strip navigation may behave independently.
Can I rely on the north/south or east/west dock preference?
A known dock-preference issue was reported, but no fix was identified. Reproduce it with the installed version and record the selected orientation and actual placement.
Does using separate clients avoid every multi-monitor issue?
Separate clients were considered as a fallback for independent windows, but the reported information does not show that they eliminate all issues. Stop deployment if popup placement, navigation, or post-update windows remain unpredictable; collect the version and reproducible steps, then escalate the specific behavior to Inductive Automation's official support channel.