Why Does a Power Table Reset Column Widths on Popup Reopen?

Direct Answer: Column Sizing Holds a Saved Width Layout

A Vision Power Table that returns to its designer column widths every time its popup reopens is almost always loading a saved width layout from its Column Sizing property. When that property contains a stored value, the table applies those widths each time the window instance is built, which overwrites whatever the operator dragged in the previous session. Empty the Column Sizing property in the Designer, save, and the popup reopens with the widths from its last use. The window cache policy and the Auto-Resize Mode setting decide how stable that behavior is.

Symptom Reading: Which Width Survives a Reopen

What matters is which width the table shows on the second open: the Designer width, the width from the last runtime drag, or a redistributed width. Each points to a different property. Test with a single controlled drag. Widen one column by a large, obvious amount, close the popup, and reopen it.

A typical case has two tables in one popup. Both are set to subsequent-columns auto-resize, and the table that was copied from the first one resets its widths on reopen. With the resize mode identical on both, the difference comes down to what each table has stored in Column Sizing.

Mechanism: Stored Layout Versus Live Component State

This is state, not logic. A Vision window resource is a serialized snapshot of every component property as saved in the Designer. When the client builds a window instance, each property is restored from that snapshot. Column Sizing is one of those properties. It is a text-encoded record of column widths. The Designer writes it when you resize columns while editing or previewing and then save. At load, a non-empty value wins, and the table lays out its columns to match.

Runtime drags change the live Swing column model inside the running client. They never write back to the project resource. If the window instance is rebuilt from the resource, a non-empty Column Sizing brings the Designer layout back. If the property is empty, the table has no stored layout to force. Widths then persist as long as the client keeps the window's state between opens.

Window caching controls whether a closed window instance is kept or rebuilt. With the default automatic policy, the client may hold a closed window in cache and drop it later. The Always policy keeps the cached instance. Caching alone does not stop a stored Column Sizing value from winning. The emptied property is what fixes the problem, and caching makes the fix hold.

Auto-Resize Mode sits on top of both. In subsequent-columns mode, dragging one column border takes or gives width to the columns to its right so the total stays at the viewport width. A reopened table can therefore look partly reset even when nothing was restored. The neighbors simply absorbed the change.

Procedure: Clearing Column Sizing and Setting Cache Behavior

1. Open the popup window in the Designer and select the Power Table.
2. In the Property Editor, show all properties so that expert properties such as Column Sizing are visible.
3. Read the current Column Sizing value. If it holds text, the table reapplies that layout on every load.
4. Clear the property so it is empty. Repeat for every table in the popup, especially any table that was created by copy/paste.
5. Do not resize columns in preview mode before saving. Doing so repopulates Column Sizing. If you must check the layout in preview, recheck the property before saving.
6. Select the window root and review Cache Policy. Set it to Always if widths must survive long gaps between opens in the same client session.
7. Decide on Auto-Resize Mode. Keep subsequent-columns if operators expect the table to fill the width. Use off if each column should keep exactly the dragged width and a horizontal scrollbar is acceptable.
8. Save the project and relaunch or update the client so it loads the new window resource.

If you need Designer default widths and runtime persistence together, store the layout outside the window resource. On the popup's closing event, read the table's Column Sizing value (hover the property to get its scripting name) and write it to a client-scoped tag or other session storage. On open, write the stored value back to the table if one exists. Otherwise, leave the Designer default in place. Test this pattern in the Designer against your Ignition version before deployment, because the load order of property bindings and window events affects which value wins.

Verification: Proving the Width Survives

1. Launch a fresh client and open the popup. Confirm the default widths load as expected.
2. Drag one column to an unmistakable width, for example roughly double its original width.
3. Close the popup, open another window, then reopen the popup. The dragged width should hold.
4. Repeat with a longer idle gap and after opening several other windows. This exercises cache eviction if the policy is not Always.
5. Repeat for every table in the popup, including copied tables.
6. Return to the Designer and confirm Column Sizing still reads empty after saving.

Width retention for the whole client session is the target. After a client restart, widths go back to defaults unless you added the tag-based storage described above.

Recurring Pitfalls on Vision Tables

• Copy/paste carries layout. A duplicated Power Table inherits the source table's Column Sizing text, even if the new table has a different dataset.
• Preview-then-save. Resizing columns while testing in preview and then saving silently writes a new layout into Column Sizing.
• Multiple popup instances. Opening a second instance of a popup builds a new instance from the resource. It does not inherit widths from the first instance's live state.
• Dataset column changes. If a binding changes the column count or names, a stored width layout no longer lines up. Clear and re-save after changing the query.
• Resize mode mistaken for reset. In subsequent-columns mode, neighbor columns change width by design. Confirm with a single-column drag test before changing properties.

FAQ