Applies to Pega Platform 7.2-8.5

Understand the behavior of Controls and Layout Actions. Learn how to prevent and resolve the issues related to Controls and Layout Actions. The scenarios describe issues with Controls and Layout Actions that users have reported. 

Controls, Layouts, and Flow Actions
Specifying Finish Assignment and Refresh Section actions
Run visibility condition on client
Debugging
Commonly reported issues

Controls, Layouts, and Flow Actions

Controls are the fields, buttons, and other user interface elements that determine what actions a user can take on a form. Use controls to display and collect data or to trigger an action.

When a control is assigned to a property, it defines the appearance of that property. For example, you can assign a .Price property with a numeric value of 1.5 to a Text input control and a Currency control. The Text input control displays the value of the property as a simple string, but the Currency control formats it to look like an amount of money by adding a Currency symbol.

Layouts help in organizing UI elements on a screen and determine the overall presentation of a portal. Layouts are used within a harness or a section to define how an application, or a section in the application, looks in different contexts and on different devices.

A flow action controls how users interact with user forms to complete assignments. After selecting a flow action, users may fill in a section of the form to complete (perform) the assignment.

In a flow, developers can associate flow actions with connectors (arrows) and with assignment shapes. At run time, the flow actions associated with an assignment determine the choices available to users as they perform the assignment.

Each flow action references a section that defines the run-time presentation of the flow action on a Layout tab. Edit the section using controls and layouts.

Specifying Finish Assignment and Refresh Section actions

Finish Assignment action

Finish Assignment action submits changes and marks an assignment as complete. Configure the Finish Assignment action as the last action in the action set while configuring a sequence of actions. The Finish Assignment action triggers form submission and loads a new document. Hence, the processing and order of actions configured after the Finish Assignment action are not guaranteed.

Refresh Section action configured with an event on a control

Refresh Section action refreshes the target (section) specified in the action parameters. When a user invokes the Refresh Section Application Programming Interface (API) directly or configures the Refresh Section action with an event on a control, multiple events trigger refresh of the same section multiple times, which can lead to stale response at some point.

Example 1

When the Refresh Section action is configured onClick of a radio button, a stale response can occur on repeatedly selecting different options.

Example 2

When a user immediately clicks Autocomplete after changing a drop-down that has the Refresh Section action configured onChange, the input elements turn stale by the time Autocomplete options data loads. The Autocomplete options load only after a section refreshes. Hence, the Autocomplete field that is clicked turns stale.

Configure the Refresh Section action to not display the Busy indicator through run script. This prevents the users from performing any actions until the Refresh Section action is complete. Add the setBusyIndicator() function before the Refresh Section action and the resetBusyIndicator() function after the Refresh Section action.

The following is the script to display the Busy indicator:

<script>
function setBusyIndicatorCustom(){
pega.u.d.busyIndInterval = 0;
pega.u.d.setBusyIndicator(null,true);
}

function resetBusyIndicatorCustom(){
pega.u.d.busyIndInterval = 2000;
if(pega.u.d.gBusyInd){
pega.u.d.gBusyInd.hide();
}
}
</script>

Run visibility condition on client

This parameter dynamically evaluates a condition each time the value of a property in the condition changes. This is available for the Condition (expression) and Condition (When rule) visibility options.

Run visibility condition on client field displays on selecting Conditional Visibility and entering a simple expression in the field that displays.

Select the Run visibility condition on client check box to cause dynamic processing of the condition each time the value of a property stated in the condition changes. This cannot be used if the expression is combined with a When condition rule.

Conditions are automatically re-evaluated when a user updates a property value. By default, controls that allow typing, such as Text Input, are evaluated when the user leaves the field. To re-evaluate conditions as the user types, use the Apply Conditions action with a Keyboard event.

Including a property in multiple sections and configuring it with the Run visibility condition on client, generates a few duplicate elements in Document Object Model (DOM) with same name or ID. Hence, the hidden values of the name or ID are submitted during form submission or post value action.

 Use the Run visibility condition on client only while using different properties in multiple sections and displaying the properties through Visible condition expression to make sure evaluation occurs at the client side rather than the server side.

Do not configure the Run visibility condition on client with a property in the same or a different section. Design such that the same property reference must not be rendered as editable in multiple places including the non-visual inputs to user and in the DOM. (A property reference must not be bound to multiple input elements in a document.)

Pega does not support the Microsoft Edge browser on Android mobile devices. However, Pega supports the Google Chrome browser and Hybrid Client app.

Debugging

• If events are triggered incorrectly, then inspect the element and verify if the data-event name attributes are stamped.
• If the continuous events cause a stale response, then use a Busy indicator.
• If the input values are not retained after form submission or post value actions, then remove the duplicate elements in the DOM by right clicking each element, clicking the Delete Element option, and retesting the use-case. This issue occurs because of the presence of multiple elements with same name or ID in the DOM as mentioned in the previous section.

Commonly reported issues

Issues with Controls and Layout Actions have been reported by users. The following scenarios describe the issues:

Scenario 1: Persistence of Clipboard values

Two Assignment steps are available to a user. The user makes changes to one of the properties in the first Assignment. However, the changes do not reflect in the second Assignment.

Explanation

Properties are configured in four different sections with the Run visibility condition on client. This generates duplicate elements on the DOM with the same name or ID.
Hence, when a form or a post value action is submitted, hidden values of the name or ID are submitted. The Run visibility condition on client option must be selected when both the following conditions exist:

• If different properties are used in multiple sections
• If the properties are displayed through the Visible condition expression such that evaluation occurs at the client side instead of the server side

Referring to the same property in multiple sections on the UI is not a supported use case. Therefore, do not configure the Run visibility condition on client on the same property in a different section.

Solution

See SA-98195, Persisting of clipboard values issue

Scenario 2: Radio buttons do not trigger configured onChange actions

Radio buttons do not trigger the actions that are configured on an OnChange event.

Explanation

When a user clicks radio buttons and moves to the next operation, the actions configured on the radio buttons are skipped from the Event queue.

Solution

See SA-83803, Radio buttons do not trigger configured OnChange actions