Actions & events

A property answers what a widget shows. An action answers what happens when someone presses it — write a tag, open a screen over the current one, load a recipe, sign a user in, raise a toast. Actions are configured, not scripted, and they compose: every action's fields are ordinary properties, so any of them can be bound to live data.

Where actions live

• On a widget — Button and Menu Toggle carry an Actions field, and a Navigation Menu item can be an action item. The list runs top to bottom on press. Other widgets run lists on their own events: On Change on a Dropdown or Button Row, On Sign In / On Sign Out / On Press on a User Badge, On Play / On Pause / On Ended / On Error on a Video, On Load / On Error / On Message on a Web Frame.
• Inside another action — an alert's OK / Cancel buttons, and the onSuccess / onFailed / onSettled handlers of the async actions below, are themselves action lists. Nesting is how a confirm-then-write flow is built.
• On the project — the Global Events node in the editor tree runs actions at lifecycle moments rather than on a press. See Global events.
• On a page or page group — an Events section in the node's properties runs actions as the operator arrives and leaves. See Page events.

Custom widgets fire the same lists through the SDK's executeWidgetActions, so a hand-built control behaves exactly like a Button.

The action catalog

Fourteen types, in the order the Add action menu lists them. Browse actions… at the top of that menu opens the same catalog as a searchable drawer, grouped as below.

Screens

Both open actions carry the presentation fields:

• Size — auto, small, medium, fullscreen, or fixed (then set Width / Height in pixels).
• Placement — center, top, bottom, left, right, or one of the trigger-anchored values (trigger-above, trigger-below, trigger-left, trigger-right) which pins the panel to the control that opened it, popover-style. Anchored placement and fullscreen are mutually exclusive.
• Backdrop — dim darkens the screen behind, none leaves it untouched (right for a small anchored popover).

Machine

Session

See Users, groups & permissions for the sign-in screen around them.

Interface

Logic

Async actions and $result

Six actions cross the wire and therefore may fail: Write Data Variable, Toggle Boolean Variable, Recipe: Load, Recipe: Save, Login User, Logout User. Each carries three optional handler lists:

• onSuccess — the server acknowledged.
• onFailed — the server refused, or the request timed out (10 seconds) or the connection dropped.
• onSettled — always, after whichever of the two ran.

Inside those handlers the $result source reads fields of what came back. Which fields exist depends on the action:

onSettled sees the union of both. The reason vocabulary is fixed, so you can branch on it with $compare:

invalid_credentials · rate_limited · permission_denied · bad_request · bad_path · bad_field · invalid_value · opcua_unreachable · write_failed · array_index_out_of_bounds · array_state_unavailable · value_unavailable · read_only · timeout · disconnected

A worked pattern — a Start button that confirms, writes, and tells the operator either way:

Button "Start"
└─ Show Alert   title "Start line 3?"  ok "Start"  cancel "Cancel"
   └─ onOk
      └─ Write Data Variable   LinePLC:Line3/Start = true
         ├─ onSuccess → Show Toast  "Line started"        severity success
         └─ onFailed  → Show Toast  { $result: "reason" }  severity error

Global events

Some things should happen because the system reached a state, not because someone pressed something. Select Global Events in the editor tree and attach action lists to:

They are scoped to the runtime that triggered them, so on a multi-panel installation each screen runs its own — one operator signing in on the line-side panel does not fire onUserLoggedIn in the control room.

Page events

onPageLoaded above fires for every page. When only one screen should react, put the actions on that screen instead: select a page or a page group and fill in its Events section.

In the Dialogs folder the same two events are labelled Dialog Open / Dialog Close and Dialog Group Open / Dialog Group Close.

A page opens and closes on every arrival and departure — a subscribe-on-arrival, unsubscribe-on-exit pair, or a write that puts a machine into the mode the screen is for.

A page group is entered and left as a whole. Moving between two pages inside the same group does not close it, so group-level actions are the place for setup that all its screens share rather than something each page repeats. Nested groups unwind in order: leaving a deep page closes the page, then the inner group, then the outer one; arriving opens them outermost-first.

Reusing a page as a modal counts too — a page shown by Open Dialog or Open Page As Overlay fires its own Open and Close events. Its groups are not entered, since nothing navigated into them. A dialog's events run with its input parameters in scope, so a Dialog Open can write the values it was opened with to the machine.

Order across the two mechanisms is fixed: the project-wide onPageLoaded runs before the arriving page's own Page Open.