Skip to content

Custom Components

Custom Components are user-defined library entries that are saved once into the project and reused across pages. They come in two flavors:

  • Custom Components — assemblies of two or more HMI components grouped under a single root (Panel, Flexbox, Grid, etc.). Use these for reusable layouts such as a machine tile, a status header, or a KPI card. Custom Components support placeholders, so the same layout can be parametrized per instance (different target variables, labels, page targets, etc.).
  • Linked Components — a single HMI component (e.g. a Label, a Numeric Output, a Gauge) saved into the library on its own. Use these when you want to reuse a single configured component in multiple places and keep every copy in sync. Linked Components do not use placeholders; every instance is visually and behaviorally identical, and the only thing an instance controls locally is its position, size and per-breakpoint visibility.

Both kinds share the same library, and editing the definition propagates to every instance automatically. Custom Components are the supported successor to the legacy HMI Templates and the Template Panel component (Linked Components, by themselves, do not replace Templates because they lack placeholder support).

Each library entry has:

  • A definition stored once in the project — the structure, attributes, styles and placeholders that every instance shares.
  • Zero or more instances placed on pages or inside other Custom Components — each instance pointing back at the same definition.

Editing the definition updates every instance immediately. This is the main reason to use Custom or Linked Components: a label color, a font, a state rule or a placeholder default only has to change in one place.

Custom and Linked Components live next to the built-in palette categories (Input, Display, Layout, Navigation, General) under a dedicated Custom category in the palette. A newly-created project starts with an empty Custom category — entries appear there as you save them from the canvas. Linked Components and Custom Components share this category; the icon next to each entry distinguishes the two.

  1. On the canvas, select two or more components that should form the reusable unit. To keep them grouped, wrap them in a Panel, Flexbox or Grid first so the assembly has a single root.
  2. Right-click the selection and choose Save to Library.
  3. Provide a name for the component. The name appears in the palette under the Custom category.

The current attributes, styles, child structure and per-breakpoint geometry are captured as the initial definition. The original selection on the page is converted into the first instance of the new Custom Component.

Creating a Linked Component (single component)

Section titled “Creating a Linked Component (single component)”
  1. On the canvas, select exactly one HMI component (e.g. a Label, a Toggle Button, a Gauge).
  2. Right-click the selection and choose Save to Library.
  3. Provide a name. The component appears in the palette under the Custom category with the Linked Component icon, distinguishing it from grouped Custom Components.

From here on, a Linked Component behaves much like a Custom Component on the canvas: drag from the palette to add an instance, edit the definition to update every instance. The two important differences are that a Linked Component’s definition is a single component instead of a group, and a Linked Component does not support placeholders — every instance is an identical copy of the definition.

Drag a Custom or Linked Component from the Custom palette category onto the canvas like any built-in component. Each drop is a new instance. The rest of this page applies to both kinds, except for the Placeholders section, which is specific to Custom Components.

What an instance can override per placement:

  • Position, size, placement and visibility per breakpoint — same controls as any other component.
  • Placeholder values — Custom Components only (see below).

Everything else — the attributes of the inner components, the structure, the state rules — is shared with the definition and follows the definition’s value automatically.

Placeholders let an instance customize text values inside the component without forking from the definition. Common uses are dynamic variable names, labels, target pages, and titles.

Open the Custom Component for editing (see Editing a library component below). On the root of the definition, add named placeholders with a default value. Each placeholder is referenced from inside the component using the syntax #name# (single hash on each side):

  • In a Label text: Line #LINE# status
  • In a target variable name: L#LINE#_M#MACHINE#_ACTIVE
  • In a Navigation Item Target page: Machine detail with placeholders LINE and MACHINE

Naming convention: use uppercase letters and underscores (e.g. LINE, MACHINE, PROD_LINE_NUMBER) so placeholder tokens stand out from surrounding text. This is a convention, not a hard rule.

When an instance is selected on a page, the properties panel shows the placeholder schema inherited from the definition. For each placeholder, the instance can either accept the default or set its own value. Empty values fall back to the definition’s default.

To change the structure or attributes of a Custom or Linked Component:

  1. Right-click an instance and choose Edit Component. The canvas switches into edit mode for the definition.
  2. Make any changes — for a Custom Component, that includes adding or removing children and editing the placeholder schema; for a Linked Component, only the single root component’s attributes and styles can change.
  3. Choose Save Component to apply the changes, or Cancel Editing to discard them.

After saving, every instance of the component across the project reflects the change at its next render (this includes pages that are not currently open).

If a specific occurrence of the component needs to diverge — gain its own children, lose a placeholder, etc. — right-click the instance and choose Unlink from Library. The instance is converted into a regular subtree of components on the page; the link to the definition is broken, and future definition edits will no longer affect this copy.

Once unlinked, the only way to bring the page back in sync is to delete the local copy and drop a fresh instance from the palette.

Behavior in legacy and responsive projects

Section titled “Behavior in legacy and responsive projects”

The single-source-of-truth behavior described above applies to responsive projects (the breakpoints workflow). In that mode, every instance is a reference to the definition and the runtime expands the definition at render time.

In legacy resolution-folder projects the instance is a one-time copy of the definition at the moment it was placed. Editing the definition later does not automatically update existing instances on other pages — the page has to be opened in the editor to re-sync. This is one of the reasons resolution-folder projects are deprecated; new HMIs should use the breakpoints workflow.

Custom Components fully cover the use cases previously served by HMI Templates (reusable page fragments with placeholders) and the Template Panel component. For new HMIs, build the reusable fragment as a Custom Component instead of a Template, and drop instances on each page where it is needed. Page-level placeholders defined under HMI Navigation still propagate into Custom Component instances in the same way they did into Template Panels.

Linked Components are not a Templates replacement — they do not support placeholders. Use them alongside Custom Components for single reusable elements (themed buttons, shared status indicators, etc.) where placeholder parametrization is not needed.