Event Triggering Order in Panels

Official Content
This documentation is valid for:

User system events have their own triggering order, according to each event and the instructions that compose them. System events such as StartRefresh, and Load are always executed on the server, and user events are usually executed on the client unless a round trip to the server is required. For example:

Event 'Message'

Here you have a user event corresponding to an action on the form, the Message button.  It is made up of a single instruction that doesn't require server services.

However, in the example below access to the server is required because the call to a Procedure is always executed there.

Event 'Message'

Event triggering sequence

Regardless of the above, basically the event triggering sequence in a Panel (either Work With for SD List or Panel object) is as mentioned in Native Mobile Applications Events:

ClientStart (List)  //since Xev3 version
Load (if there is any non-SDT-based grid on the layout)

If the Panel corresponds to the Work With Detail with N sections, the events will be triggered as follows: First, Detail system events will be triggered (i.e. Start, Refresh and Load events associated to the Detail node of the WWSD). After that, depending on the sections:

  • If the sections are displayed as Tabs, each section is activated when the tab is first selected (or at startup for the first tab). So, its system events are triggered. After navigating the tab you can select it again, but none of the System Events will be executed for that section (since it is already "online"). If you exit the containing object and press Back this will execute all the System Event tabs again.
  • If the sections are displayed as Links, each section is activated (and so system events are triggered) when the link is executed.
  • If the sections are displayed Inline, each section is activated in an indeterminate (and possibly concurrent) order.
  • When invoking a BC in insert, update or Delete mode (WWSD.Detail.Insert() / WWSD.Detail.Update(pk) / WWSD.Detail.Delete(pk)), this won't execute neither the Start nor the Refresh event (the default rules for the BC itself will be applied instead). However, the Detail Start event will be executed.

Schematically, that is:

ClientStart (Detail) //since Xev3 version
Start (Detail)
Refresh (Detail)
Load (Detail, if there is any non-SDT-based grid)
    ClientStart (Section 1) //since Xev3 version
    Start  (Section 1)
    Refresh (Section 1)
    Load (Section 1, if there is any non-SDT-based grid)
    ClientStart (Section n) //since X Evo3 version
    Start (Section n)
    Refresh (Section n)
    Load (Section n, if there is any non-SDT-based grid)

executing the Section m ClientStart-Start-Refresh-Load sequence under the above considerations.

After loading the screen, the user is ready to interact. What happens when the user triggers an action (client event)? The associated code is executed on the client-side, that is, in the device, unless a roundtrip to the server is required (for example, when a procedure must be invoked). In any case, system events are not executed (unless they are explicitly required through the Refresh command).

What happens when the Refresh command is reached inside an event?

Depending on the caching settings it is decided whether the device should go and retrieve data from the server.

After going to the server, if there are no changes in the server data, nothing is brought back to the client. Otherwise, the Refresh and Load (if there is a non-SDT-based grid) events are executed.

What if the Refresh command is executed on a client event of a Detail section? The system events for the Detail node will be executed, as well as the sections that were previously activated (except for those Inline, that will be activated at any time, as mentioned above).

See also

Native Mobile Applications Events
Server-side Events in Native Mobile Applications
Refresh event
Load event