Set up a persistent HMI layout for changing screens

Separate the parent view from the content

The parent view is the shell that stays open. It contains the shared navigation, screen title area and any common status information. An embedded view object occupies the remaining content area. Your software may call this object a picture window, screen window or view container.

Each destination screen belongs inside that container. It should not contain another copy of the shared header or footer.

Two common arrangements work:

A shared pane usually makes layout maintenance easier because its position and dimensions have one owner. Preassigned panes can be simpler when there are few destinations and the software provides straightforward visibility controls.

What you need

Before editing, gather:

• A backup of the HMI project and a way to restore it.
• The parent view that should remain open during navigation.
• The child screens that will occupy the content area.
• A list mapping each clickable process object to its destination.
• The runtime documentation for embedded views, object scope and navigation events.
• A development runtime or simulator, followed by access to the intended display for layout checks.

This setup needs an HMI runtime with suitable embedded-view support. A factory status display and an operator HMI serve different purposes; showing exported images is not a substitute for configuring interactive process navigation.

Configure the content pane

1. Define the content rectangle. Reserve space for the header, footer and shared navigation. Position the embedded pane within the remaining area. Check whether borders, captions or scrollbars reduce its usable interior. Size child screens for that interior, not just the pane's outer dimensions.

2. Move common elements into the parent. Keep shared controls and status indicators outside the embedded pane. Remove duplicate header and footer elements from child screens. Leave only content that belongs to that particular process view inside each child.

3. Choose one navigation arrangement. For a shared pane, assign a known initial child screen. For preassigned panes, configure one destination per pane and establish which one is visible at startup. Avoid mixing both arrangements unless there is a clear reason and a documented navigation map.

4. Give the pane a stable object name. Use that same target for every navigation action. Keep position and dimensions in the parent configuration where possible. Repeatedly setting geometry in individual click actions creates more places for layout settings to disagree.

5. Bind each process object to its destination. Use the runtime's documented action for changing an embedded screen. Target the content pane, not the action that replaces the main runtime view. For preassigned panes, make the selection mutually exclusive: show the selected pane and hide the other destination panes.

6. Check the action's object scope. A navigation button in the parent and a process object inside a child may execute in different view contexts. Confirm how the runtime resolves the target pane from each location. A name that works from the parent may need a documented parent reference when called from a child. Do not assume identical names refer to identical objects across view levels.

7. Keep titles and selection indicators consistent. Update the parent title and selected navigation state when the destination has loaded, using the runtime's documented load event if loading is asynchronous. If loading fails, retain a clear error state rather than displaying a new title above old content. Avoid tying visibility changes to an assumed loading delay.

If scripts are necessary, keep destination selection separate from layout configuration. Each clickable object should supply its destination; the shared navigation routine should handle the pane consistently. Use the software documentation for the actual function names and event sequence rather than transferring code from another runtime.

Check the layout in runtime

Verify the project in a non-production environment first. Then inspect it at the intended runtime resolution and display scaling before commissioning.

Use this acceptance list:

• Open the parent view and confirm the intended initial child appears.
• Select every mapped process object and confirm the correct destination opens inside the content area.
• Confirm the header, footer and shared navigation remain visible and do not reload during a child-screen change.
• Repeat navigation from controls inside child screens, not just from the parent navigation bar.
• Check every edge of each destination for clipped labels, hidden buttons and unwanted scrollbars.
• Navigate back and forth repeatedly, including between screens with different content density.
• Confirm the displayed title and selected navigation state match the loaded content.
• In the development copy, check how an unavailable destination is reported without disturbing the surrounding shell.

If the content pane contains a browser, also check its own viewport and scaling. Kiosk browser sizing is a separate issue from the position of the HMI container around it.

Trace faults to the correct layer

A layout problem is easier to diagnose when you identify what actually changed:

• The header and footer disappear: the action probably replaced the parent view instead of changing the embedded destination.
• Navigation works from the header but not from a process object: check event binding and the child action's reference to the parent pane.
• Two destinations overlap: check that preassigned panes have mutually exclusive visibility states.
• Content is cropped: compare child dimensions with the pane's usable interior, including borders and captions.
• The title changes but the process screen does not: check destination loading and when the title update occurs.
• A hidden destination still runs scripts: hiding and unloading are different operations in some runtimes. Check the documented lifecycle behavior before choosing the arrangement.

Correct the navigation target or lifecycle configuration rather than covering an unwanted view with another object.

Keep navigation separate from machine control

Changing a view should not itself issue a process command. Review event bindings so a navigation click cannot also start equipment, reset a fault or change a setpoint unintentionally.

Preserve the application's authorization checks for every command. A hidden button or hidden pane is not access control. Likewise, persistent on-screen status information does not replace a machine's required safety functions.

Before deployment, record the parent view, pane name, destination mapping and startup behavior. Keep that record with the project backup so later changes do not accidentally turn embedded navigation back into full-screen replacement.

Questions