Applies to Pega Platform 7.2-8.5
Controls are the fields, buttons, and other User Interface (UI) elements that determine what actions the user can take in a form. You can use controls to display and collect data, or to trigger an action.
Pega Platform provides a wide variety of out-of-the-box behavior patterns (actions) that can be added to a UI element to make it more responsive. For example, the Refresh action refreshes a UI element that the action parameters specify, and the Refresh-Other Section action affects all the sections in the view that have the same name.
Linking a specific user behavior (event) to the desired outcome of that behavior (action) determines how a control behaves when the user interacts with it.
Understanding the causes of stale UI elements in your application is important to avoid commonly reported issues.
Inspect a UI element in your browser's Developer tools. If the web browser console throws an undefined element error, or is unable to invoke a method or find a property of an undefined element error, then the UI element is stale.
The following conditions cause stale UI elements in the Document Object Model (DOM):
- One of the actions is a Refresh action (such as Refresh-Section, Refresh-Harness, Finish-Assignment, or Post-Value) and it is followed by another action.
- Deleting the Refresh action (such as Refresh-Section, Refresh-Harness, Finish-Assignment, or Post-Value) on the element fixes the issue.
- A section is refreshed twice for the same action that is configured on the section.
- The action set configuration of a UI element in a modal dialog window is contradictory.
Scenario 1: Configuring actions on UI elements after Finish-Assignment action
Configuring the Finish-Assignment action on a UI element refreshes the element. Because the Finish-Assignment action redirects the flow to the next section, all UI elements in the previous section turn stale. Thereafter, if other actions are configured on the same UI element that is stale, these actions are unsupported because the basereference value for the stale UI element is empty or null.
Scenario 2: Configuring Refresh-Section action on UI elements that launch a modal dialog window
Configuring the Launch-Local-Action action on a UI element launches a modal dialog. If the Refresh-Section action is configured on the same UI element (that launches the modal dialog) and the modal dialog is closed, the Refresh-Section action is unsupported. Closing the modal dialog refreshes the underlying section that includes the UI element. Hence, the UI element turns stale. Actions configured on a stale UI element are unsupported because the basereference value for the stale UI element is empty or null.
Scenario 3: Configuring Set-Focus action on UI elements after Refresh-Section action
Actions such as Set-Value, Set-Focus, Set-Style become useless if the action’s target UI element (for example, a button) is inside a section that refreshes on the previous Refresh-Section action, Refresh-Other-Section action, or Refresh-Harness action. The UI element becomes stale after section refreshes. The actions, which are configured on the same stale UI element, are unsupported because the basereference value of the stale UI element is empty or null.
The following approaches prevent UI elements from turning stale, but they do not guarantee the complete resolution of issues caused by stale UI elements.
- Display a busy indicator while a UI element is being refreshed. This prevents another action from being triggered on the same UI element during the short time interval.
- Invoke an activity, configured with the Wait method, after a UI element refreshes. Configure the waiting time such that it is longer than the time taken by the web browser to refresh the element.
- Develop an optimal UI design to prevent explicitly refreshing a section twice.