Why Does Perspective Property Editor Show Stale Data?

The failure presents as a Designer user-interface state problem: the selected component changes, but the floating Property Editor continues to show the previous selection, becomes blank, or combines fields from two selections. Before anything else, confirm the active Perspective container, the deep-selected object, and whether the Property Editor is floating or docked.

Recovery approaches and selection criteria

Use deep selection first because it resolves selection-context ambiguity without changing the workspace. If the displayed properties remain stale or blank, force a redraw by moving the floating panel. When that recovery lasts for only one selection, reset the panels. Keep the editor docked as the practical operating configuration while diagnosing repeated redraw failures.

Affected condition pattern

The reported installation used Ignition Platform 8.1.47, Perspective Module 2.1.47, and Windows 11 25H2 with OS build 26200.7840 and Windows Feature Experience Pack 1000.26100.291.0. These values identify the tested environment; they do not define every affected release.

The container correlation matters. Test first in the container where the problem began rather than switching immediately to a Coordinate, Split, or Tab Container. A stale panel can persist across that transition and can display part of the old container's property set beside part of the current selection's properties.

Selection and redraw mechanism

The Project Browser selection, canvas highlight, and deep-selection context represent related but distinct editing states. A child can appear selected on the canvas while the root or another container remains the active deep-selected object. In that state, the Property Editor may correctly follow the editing context even though the visible highlight suggests a different target.

A separate redraw fault produces a similar symptom. The internal selection may change while the floating panel fails to repaint its controls. Dragging the title bar causes Windows to reposition and repaint the panel, exposing the properties already associated with the current selection. Mixed old and new property fields point more strongly to an incomplete panel redraw than to a simple selection mistake.

This distinction defines the diagnostic path: inspect deep selection before treating the problem as a rendering fault. Do not move on until the Project Browser identifies the intended editing object. If the identity is correct but the display remains stale, recover the panel rather than repeatedly changing the project selection.

Controlled recovery procedure

1. Record the failing context. Note whether the active view uses a Break, Column, or Flex Container and whether the Property Editor is floating. Select two components with visibly different property sets. Confirm that the second selection still shows the first component's properties, a blank editor, or a mixed property display.
2. Set the editing context. In the Project Browser, right-click the required component or container and choose Deep Select. Confirm that the intended object, rather than the view root or another container, is deep selected.
3. Retest selection tracking. Select the target again and wait for the Property Editor to update. If the displayed object now matches, continue editing with that deep-selection context. If the identity remains stale, proceed to the repaint test.
4. Force one repaint. Click the floating Property Editor title bar and drag the panel. Confirm that the panel immediately displays the current component's properties. This separates a repaint failure from an incorrect component selection.
5. Reset persistent panel state. When the next selection again leaves stale content, use the toolbar's View option and click Reset Panels. Confirm the restored panel layout before testing another component.
6. Apply the stable layout. Dock the Property Editor if floating operation continues to fail. Confirm that it follows selections, allowing for the reported delay in Break, Column, and Flex Containers.

Verification matrix

Run the verification in a fixed order so that a container transition does not hide retained panel state.

1. Open a Perspective view containing one of the affected container types: Break, Column, or Flex.
2. Deep-select the container root, select a child component, and confirm that the editor identifies the child and displays a complete property set.
3. Select the root again. Confirm that no child properties remain and that the panel does not go blank.
4. Repeat the child-to-root transition several times without dragging the panel. Any required title-bar movement means the recovery is temporary.
5. Open a Coordinate, Split, or Tab Container only after the affected-container test passes. Confirm that no fields from the previous Break, Column, or Flex Container remain visible.
6. Repeat once with the panel floating and once docked. Record whether the failure is stale content, blank content, mixed content, or delayed content; these observations separate repaint failure from slow refresh.

Recurring diagnostic pitfalls

• Trusting the canvas highlight alone: The highlighted component may differ from the deep-selected editing context. Verify both before resetting panels.
• Using panel movement as the permanent fix: A successful repaint proves that dragging can refresh the display, but the next selection can reproduce the problem.
• Testing only an unaffected container: Coordinate, Split, and Tab Containers can appear normal after the panel has been redrawn. Reproduce and verify in Break, Column, or Flex first.
• Reading silence in the Console as proof of recovery: No Console errors were produced during the failure. Visual selection tracking is the required test.
• Confusing delay with stale state: A docked panel may update slowly. Wait for the update, then compare the displayed object and property set with the current selection before changing the layout again.

FAQ