Behaviours

Behaviours define advanced logic for a form element. In general, behaviour configuration links the following three components:

  1. Events (Form designer) (e.g. Click or Changed), that determine the events that cause the behaviour to be executed.

  2. Evaluation logic referred to as a Behaviour type (e.g. Filled mit or Items selected), which always returns a Boolean value (‘true’ or ‘false’) and possibly also certain ‘behaviour data’.

  3. Actions (e.g. Show alert or Set value), which are executed depending on the Boolean value from the behaviour – as Actions on ‘true’ or Actions on ‘false’.

It is significant that the configuration of a behaviour can specify no or several Events (Form designer) and also no or numerous Actions but must always address exactly one behaviour type. Because of this close (1:1) relationship between a behaviour and the behaviour type it addresses, simplified language in the product and in the manual sometimes refers to ‘behaviour’, where a behaviour type is actually meant.

NOTE◄ If multiple behaviours with the same Events (Form designer) are defined for the same element, they are executed according to their sequence position (from top to bottom).

Simple example

The screenshot shows a sample configuration for a behaviour named ‘Air freight alert’ that checks if the 'Freight type' Text field (element #3) is filled with the value ‘AIR’ when the Button, for which it was configured, is clicked. If this is the case (i.e. on ‘true’), an alert is displayed, by configuration not to be presented in detail here.

images/download/attachments/189435639/image-2024-10-22_11-46-8-version-1-modificationdate-1729590368135-api-v2.png

Details (from top to bottom):

  • Via the symbols images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/add.svg and images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/forbidden.svg , a new behaviour can be added or an existing one removed.


  • From the header line, the grey frame covers the entire behaviour in its expanded state. The Name is set below in the Behaviour name field. On one hand, it is used to identify the behaviour, especially in the collapsed state, but on the other, it also serves as a reference to the behaviour in certain cases (e.g. by the Logical condition behaviour type or the action Execute behaviour).

    NOTE◄ If multiple behaviours are configured for the same form element, they can be re-sorted in the header using drag & drop. Shortcuts can also be used to completely copy (Ctrl+C), cut (Ctrl+X) and paste (Ctrl+V) selected behaviours. A copy can also be created by using drag & drop while holding down the Ctrl key.


  • The Triggering event field defines Events (Form designer) for the behaviour via multiple selection. The choices depend on the type of the parent form element, also called the executing element of the behaviour. In the example, clicking the button serves as a trigger. The Triggering event field can also be left empty if a behaviour is to be invoked exclusively by other logics, such as the Logical condition behaviour or the action Execute behaviour.


  • In the Execute later once (ms) field, an optional time delay can be entered as an integer number of milliseconds (ms), to define a so-called ‘debounce’ for the execution of the behaviour. Each time one of the Events (Form designer) of the behaviour is activated, a timer with the specified delay time is started. Processing of the Behaviour therefore only starts if no further triggering takes place before this timer expires. A typical application for this technique is the joint evaluation of keyboard entries for a text field, where the string entered is often only to be processed if no further characters or keystrokes follow within the delay time (see Trigger Changed).

  • Wait for later execution: If a delay (value > 0) is defined, calling instances are not waiting for the behaviour to finish, if the displayed option "Wait for later execution" is deactivated. This affects calling other behaviours via action or loading form data.


  • The section Behaviour, which can be collapsed, defines the Behaviour type which is the logical core of the behaviour configuration. Often the behaviour type has an evaluative or validating character, so that an element must be linked as a reference object unless the behaviour type should operate ‘reflexively’, i.e. with reference to the executing element. In the example, the behaviour Filled with was selected, which provides information on a compared value (here: ‘AIR’) and a link to the reference object of the evaluation (here: Text field ‘Freight type’ aka. element #3).

    The link to a form element is initiated by clicking on the chain symbol, if no link exists. Then the target element must be clicked on directly or in the tree structure of the form editor to establish the link. An existing link is removed by clicking on the corresponding chain symbol.


  • The sections Actions on ‘true’ and Actions on ‘false’ define an optional list of Actions for the respective evaluation results of the behaviour. At runtime, precisely one of these lists is always processed sequentially, as long as an error does not cause processing to be terminated.

    NOTE◄ Already configured actions can be moved in and between these lists via drag & drop and copied (Ctrl+C), cut (Ctrl+X) and pasted (Ctrl+V) via shortcuts. Copying actions are also possible by drag & drop while holding down the Ctrl key.