You are here:

'actions' and 'actions_on_done': Managing Built-In and Customized Action Events

'actions’ Setting Overview

Adding Custom Actions

Disabling the Built-In Actions

Example Demo Program: settings_actions_insert_field_after

Example: Record Edit Mode on DOUBLECLICK in DISPLAY ARRAY (List View)

'actions_on_done': Arranging Custom Actions Execution After the Built-In Actions

Using the ON CHANGE Clause With Lycia LowCode

The Function Signature

'actions' Setting Overview

actions defines a list of custom actions that should be added to the interaction and executed before the built-in actions. Also, it can be used to disable the built-in actions. It is an optional setting, and a HASHMAP OF HASHMAP.

Note: Before proceeding, get acquainted with the Settings Levels section of LyciaLowCode Settings page (the concept of scopes is essential for configuring multiple interactions and the multitable support).

The definitions like LET <setting_variable>.<setting_name> = <value> refer to the InteractForm_Settings level, while LET <setting_variable>.views["<db_table_name>"].<setting_name> = <value> refers to the View level.

This setting can be defined for:

InteractForm_Settings level: Yes

View level: Yes

Adding Custom Actions

Setting format for the entire form:

LET <InteractForm_Settings>.actions[Parent Event ID][Event ID] = <call the function without any arguments>

Setting format for the View:

LET <InteractForm_Settings>.views["<db_table_name>"].actions[Parent Event ID][Event ID] = <call the function without any arguments>

The key of the first HASHMAP is the name of sub-interaction. If key is an empty string, actions are added to the main interaction (DISPLAY ARRAY or INPUT ARRAY).

DISPLAY ARRAY interaction has several sub-interactions (UPDATE, INSERT and QUERY), so you need to define the name of sub-interaction for defining actions for a specific interaction.

The key of the second HASHMAP is the action name in full format like ON ACTION myact. The value of second HASHMAP is a function that should be executed on triggering the defined action.

<InteractForm_Settings> here is the settings variable name you define.

Example 1:

LET settings.actions[""]["BEFORE DISPLAY"] = FUNCTION custom_before_display

LET settings.actions[""]["ON ACTION Accept"] = FUNCTION table_view # Adding custom action

Example 2:

LET p_rec_settings.views["contact"].actions[""]["ON ACTION ContactOnly"] = FUNCTION ContactOnlyFunc

Note: Alternatively, you can specify this setting in JSON array in .fm2 form file by the following example: Defining Settings in .fm2 Form File.

Return to top

Disabling the Built-In Actions

If you set the function call to NULL, this will disable the corresponding built-in action. See the examples below:

LET settings.actions[""]["ON INSERT"] = NULL # Hide action INSERT

LET settings.actions[""]["ON APPEND"] = NULL # Hide action APPEND

LET settings.actions[""]["ON DELETE"] = NULL # Hide action DELETE

LET settings.actions[""]["ON UPDATE"] = NULL # Hide action UPDATE

Return to top

Example Demo Program: settings_actions_insert_field_after

Example program function, which uses the actions setting:

FUNCTION settings_rec()

DEFINE l_settings InteractForm_Settings

LET l_settings.form_file="../llc_settings/llc_settings_rec"

LET l_settings.actions["INSERT"]["AFTER FIELD test05_int" ] = FUNCTION actions_insert_after_field_test05_int

CALL InteractForm(l_settings)

END FUNCTION

Example function, called by the AFTER FIELD action event:

FUNCTION actions_insert_after_field_test05_int(iform InteractForm INOUT) RETURNS BOOL

DEFINE dlg ui.Dialog

DEFINE l_rec_test05 RECORD LIKE test05.*

DEFINE l_msg STRING

#You can do any field validation here and update/change the data

CALL display_dialog_record(iform)

RETURN FALSE # Means that built-in function should not be prevented

END FUNCTION

Return to top

Record Edit Mode on DOUBLECLICK in DISPLAY ARRAY (List View)

When the data is displayed in a form of the list (DISPLAY ARRAY, List View), double-clicking on any row will invoke another Lycia LowCode process that will offer the user to edit the corresponding row in a Detailed Record View:

FUNCTION settings_list()

DEFINE l_settings InteractForm_Settings

LET l_settings.form_file="../llc_settings/llc_settings_list"

LET l_settings.actions[""]["ON ACTION DOUBLECLICK"] = FUNCTION settings_rec_input

LET l_settings.actions[""]["BEFORE ROW"] = FUNCTION actions_set_m_pk

CALL InteractForm(l_settings)

END FUNCTION

Return to top

'actions_on_done': Arranging Custom Actions Execution After the Built-In Actions

The actions_on_done setting triggers the execution of a custom action after the built-in action:

LET settings.actions_on_done[""]["BEFORE DISPLAY"] = FUNCTION custom_func()

This setting can be defined for:

InteractForm_Settings level: Yes

View level: Yes

Return to top

Using the ON CHANGE Clause With LyciaLowCode

To trigger the action with a change event, provide the fields for ON CHANGE clause in the second HASHMAP. There are three available options:

Action triggered on change of one field:

LET settings.views["contact"].actions["INSERT"]["ON CHANGE contact.cont_email" ] = FUNCTION xxx

Action triggered on change of multiple fields:

LET settings.views["contact"].actions["INSERT"]["ON CHANGE contact.cont_fname, contact.cont_email" ] = FUNCTION xxx

Action triggered on change of any active field:

LET settings.views["contact"].actions["INSERT"]["ON CHANGE *" ] = FUNCTION xxx

Note: You can use the ON CHANGE clause with actions setting for a custom action execution before the built-in action, and with actions_on_done setting for a custom action execution after the built-in action.

Return to top

The Function Signature

For the function to be used as definition for the actions setting, and manage the built-in actions (or disable them), it must have one argument, receive the reference for current Lycia LowCode process record data (iform), and return the BOOLEAN status:

FUNCTION <function_name>(iform InteractForm INOUT) RETURNS BOOL

The function should return TRUE if it should prevent built-in / predefined action processing, and it should return FALSE if it should not prevent built-in / predefined action.

TRUE = Overwrite / Ignore processing the built-in action (only process the custom action code)
FALSE = Process the custom action code first, and then the built-in action code.

Example:

FUNCTION custom_before_display(iform InteractForm INOUT) RETURNS BOOL

CALL fgl_winmessage("BEFORE DISPLAY")

RETURN FALSE # Process the custom action code first, and then the built-in action code.

END FUNCTION

Return to top