How Do Ignition Vision Screens Pass Parameters Reliably?

The operator enters a value on one main window, selects another tab, and sees the new window open with an empty or stale field. The navigation window may already contain the correct value, and no script error appears. What the screen is telling you is that the value exists, but the destination did not read it at the right point in the window swap.

Choose the transfer method from the lifetime of the destination. Write directly to a custom property when both windows are open. Use a Vision client tag when the destination may be closed. A closed window has no in-memory component tree, so no script can update one of its properties.

Where should the shared value live?

Start by deciding whether the value belongs to a window instance or to the Vision client. This determines whether the design survives navigation that closes one main window before opening another.

For eight mutually swapped main windows, use a client tag. It removes the need to address seven closed destinations or coordinate a write-to-navigation event with a read-on-open event. The navigation property can also work when event order is explicitly controlled, but the client tag matches the lifetime of a value shared across the client.

Check: close one main window and confirm that the chosen storage location still exists. If it disappears with the window, it is not global client storage.

How do I connect each screen to the shared value?

Create one client tag for the shared string, then bind the common text field on every main window to that tag. Use a bidirectional binding when an operator must be able to edit the value from any of those windows. A one-way binding is sufficient when screens only display a value written elsewhere.

The tag is right; the binding is wrong when the client tag changes but the visible field does not. Check that each field points to the same client tag, that the binding direction matches the required behavior, and that no component event script immediately replaces the bound value with a default.

1. Open the first main window and locate its common text field.
2. Bind the field value to the shared client tag.
3. Configure the binding as bidirectional if edits on this window must write back.
4. Repeat the same binding on the corresponding field in all eight windows.
5. Remove window-open copy scripts that compete with the binding for the same field.

Check: edit the field on one open window and read the client tag. The tag must show the edited string before navigation begins.

How do I pass the value directly between open windows?

Direct property transfer remains useful for docked windows because those windows can stay open while a main window changes. Obtain references to both live window instances, read the source component, and assign the value to a custom property on the destination Root Container.

window1 = system.gui.getWindow("Window1Name")
window2 = system.gui.getWindow("Window2Name")
text = window1.rootContainer.getComponent("TextField1").text
window2.rootContainer.customProperty = text

The names supplied to system.gui.getWindow() must identify currently open windows. The destination property must also exist at the path used by the assignment. If either window is closed, its component hierarchy is unavailable and this transfer cannot succeed.

Run the transfer from the event that owns the value change or navigation action. This keeps the write and the user action in one controlled sequence instead of splitting them across unrelated lifecycle events.

Check: keep both windows open, trigger the script, and display or inspect window2.rootContainer.customProperty. Its value must match TextField1.

How do I avoid writing to a closed window?

Use system.gui.getOpenedWindowNames() before accessing an optional docked or popup window. It returns the names of open windows, allowing the script to update only live instances and provide an operator message when a required destination is absent.

sourceName = "Window1Name"
targetName = "Window2Name"
opened = system.gui.getOpenedWindowNames()

if sourceName in opened and targetName in opened:
    window1 = system.gui.getWindow(sourceName)
    window2 = system.gui.getWindow(targetName)
    text = window1.rootContainer.getComponent("TextField1").text
    window2.rootContainer.customProperty = text
else:
    # Handle the unavailable window in the project's normal operator workflow.
    pass

This guard prevents the script from treating a closed destination as an addressable object. It does not make a closed window writable. If the value must appear when that window opens later, write the value to the client tag instead.

Check: execute the guarded transfer once with both windows open and once with the target closed. The first case must update the property; the second must take the unavailable-window branch without attempting the property assignment.

Why does copying through the navigation window fail during a swap?

A tab strip using Swap to Window closes one main window and opens another. If the source writes its value during visionWindowClosed while the destination reads during its window-open event, the two lifecycle callbacks can execute in an order that lets the destination read first. The navigation window then shows the correct value afterward, but the new field remains stale because its one-time read has already occurred.

Moving the source write earlier can make the navigation-property design work: store the value before initiating the swap, then let the destination read it when it opens. That design still depends on every navigation path following the same order. A client-tag binding is preferable for the eight-window arrangement because the new window reads current client state through its binding rather than through a one-shot relay script.

1. Write the edited value to the client tag before requesting navigation.
2. Allow Swap to Window to close the source and open the destination.
3. Let the destination field binding obtain the current tag value.
4. Use direct property writes only for other windows confirmed to be open.

Check: watch the client tag during a swap. It must change before the destination field appears, and the new field must display that same value without a window-open copy script.

How do I verify the complete navigation path?

Test the configuration as an operator will use it, including edits from more than one window. A single successful transition does not test reverse navigation, closed-window behavior, or competing scripts.

Check: make the final edit on one window, traverse all eight tabs, return to the first window, and verify that every common field and the client tag contain the identical string.

FAQ