Changed
Triggering event – Abstract
This is triggered when the value of an element or the element data has been 'changed'.
►SPECIAL CASE◄ When loading form data, ‘Changed’ is triggered independently of changes if the change type ‘Form data loaded’ (see below) is selected.
The data that is transferred to the behaviour corresponds to the changed state of the element (see Beispiel below).
The selection of Change types can be used to set the cases in which the trigger should react to a change
Four different change types are distinguished, which can also be combined by multiple selection. If no change type is explicitly selected, the trigger reacts to all change types.
Change type |
Description |
Form data loaded |
The form data was loaded or reloaded, for example, because a business object was selected in an overview or after ‘New’ or ‘Save’.
|
Exclusively by the user(default value) |
The user has changed the value of the element manually and directly. Other events (such as Focus out or Key pressed may also be better suited to respond to text entries. Both examples require a certain degree of cooperation on the part of the user, who must then leave the field or press the ‘Enter’ key to formally complete the input. |
Element data changed |
The element data has changed depending on the data field or through an action 'Populate element data'. The term ‘element data’ refers to the data content that was actually transferred to the form data for an element. The Value of an element may differ from this element data if the element was changed interactively (see previous change type) or by program logic (see the following change type) and has not been validated since. The validation of all elements takes place when saving at the latest, but can also be triggered specifically for a certain element by Behaviours in the form (Validate element or Validate element and call profile). |
Value set by program |
The Value of the element was changed by a program logic e.g. by the action 'Set value' or by a Berechnung. |
Example: Synchronizing text fields
This simple example shows how the value of one text field is simultaneously propagated to another text field. The value of the second text field is thus synchronized with the value of the first.
The screenshot above shows the configuration of the ‘Source’ text field. All (2) changes (1) of the value should be responded to. As behaviour ‘Statically true’ (3) was chosen, which transfers the event data to all Actions on ‘true’. The only action is the action 'Set value' (4) on the text field ‘Target’ and the input data (5) of the action serves as the value, which then corresponds to the data of the trigger ‘Changed’.
The result is demonstrated in the next image.