Block Events and Parent-Screen Communication

Block Events and Parent-Screen Communication

Quick Answer: A Block Event is the OutSystems mechanism for a Block to notify its parent Screen that something happened inside the Block — a button click, a list selection, a form save. The Block raises the Event using the Notify action, and the parent handles it through a Client Action bound to the Block instance's OnNotify property. Event parameters carry data from the Block to the parent, completing the upward half of the parent-child communication cycle.

The Raise/Notify Pattern

Blocks cannot directly call parent Screen actions — they are encapsulated and do not know which Screen hosts them. Instead, Blocks use an event-driven publish-subscribe pattern:

1. Define a Block Event in the Block's element tree, specifying Event parameters (the data the Event will carry)
2. Raise the Event inside the Block's logic using the Notify action, passing current values into the Event parameters
3. Handle the Event on the parent Screen by binding a Client Action to the Block instance's OnNotify property
4. React in the handler Client Action, reading the Event parameters and executing parent-side logic

This decoupling makes Blocks reusable. The same Block on different parents handles the Event differently — OnSaveClicked might trigger a data refresh on a list Screen and a navigation on a wizard Screen.

Event Parameters: Passing Data from Block to Parent

When you define a Block Event, you specify its parameters — the payload carried to the parent. These function like Event outputs:

Inside the Block, the Notify action passes values into these parameters — typically from local variables or widget bindings. On the parent side, the handler receives them as read-only inputs to call a Server Action, navigate, refresh an Aggregate, update a local variable, or show a Feedback Message.

OnNotify: The Parent-Side Handler

When you drag a Block onto a Screen, the Block instance exposes an OnNotify event property. You bind a Client Action to it — this is the event handler. When the Block raises any Event via Notify, the OnNotify handler runs on the parent.

If a Block defines multiple Events, all funnel through the single OnNotify handler; you distinguish which fired by checking the Event name or using a Switch node on an identifier parameter. The handler signature includes the Event's parameters as inputs, so you can read them, execute parent-side logic, and access Screen-level local variables since the handler is a Client Action in the parent Screen's context.

Parent-to-Block: Input Parameters (Downward)

The downward direction uses input parameters. The parent passes values when it places the Block:

• Bind the Block's input parameter to a Screen local variable, expression, or Data Action result
• When the parent's bound value changes, the Block's OnParametersChanged fires automatically
• The Block can call RefreshData on its Data Actions inside OnParametersChanged to re-fetch with the new parameter value

This creates a clean separation: input parameters are the downward channel (parent to Block), and Events are the upward channel (Block to parent). Neither channel works in reverse — a parent cannot raise a Block's Event, and a Block cannot set its own input parameter. This asymmetry is a frequent exam topic.

The Full Parent-Child Communication Cycle

The complete bidirectional pattern ties both channels together:

This five-step cycle — configure down, detect internally, fetch, notify up, react — is the canonical Block communication architecture. Scenario questions often describe a subset and ask which mechanism (input parameter, OnParametersChanged, RefreshData, Event, or OnNotify) belongs at each step.

Common Exam Traps

Several traps recur in Block and Event questions:

• Trap: "Use a Block output parameter to send data to the parent." Blocks do not have output parameters — they use Events with Event parameters. An output parameter is a Server Action concept, not a Block concept.
• Trap: "The parent can read the Block's local variables." Local variables are internal; the parent cannot access them. If the parent needs the data, the Block must raise an Event carrying the value.
• Trap: "A Block can call a Server Action defined in the parent Screen." Blocks cannot reference parent Screen actions directly — communication is through Events (upward) and input parameters (downward).
• Trap: "OnNotify fires before the Block renders." OnNotify fires when the Block raises an Event during user interaction, not during render. OnParametersChanged is the lifecycle event for input parameter changes.

When to Use Events vs Input Parameters

• Need the parent to configure the Block? Use input parameters (e.g., pass a CustomerId or ReadOnly flag)
• Need the Block to tell the parent something happened? Use an Event (e.g., OnSaveClicked, OnItemSelected)
• Need both? Most real-world Blocks use both: input parameters configure the Block, and Events report user actions back. This bidirectional pattern — input parameters down, Events up — is the standard architecture for reusable Blocks in Reactive Web Apps.