Skip to Main Content
Return to Navigation

PeopleCode Events

This section discusses:

Note: The term PeopleCode type is still frequently used, but it does not fit into the PeopleTools object-based, event-driven metaphor. The term PeopleCode event should now be used instead. However, it’s often convenient to qualify a class of PeopleCode programs triggered by a specific event with the event name; for example, PeopleCode programs associated with the RowInit events are collectively referred to as RowInit PeopleCode.

Activate Event

The Activate event is initiated each time that a page is activated, including when a page is first displayed by a user, or if a user presses Tab between different pages in a component. Each page has its own Activate event.

Activate PeopleCode associated with a popup page execut after the page activate event for the main page. When fields on the main page change and trigger updates on the popup page the page activate event for the popup page is executed.

The Activate event segregates PeopleCode that is related to a specific page from the rest of the application’s PeopleCode. Place PeopleCode related to page display or page processing, such as enabling a field or hiding a scroll area, in this event. Also, you can use this event for security validation: if an user does not have clearance to view a page in a component, you would put the code for hiding the page in this event.

Note: PeopleSoft builds a page grid one row at a time. Because the Grid class applies to a complete grid, you cannot attach PeopleCode that uses the Grid class to events that occur before the grid is built; the earliest event you can use is the Activate event. The Activate event is not associated with a specific row and record at the point of execution. This means you cannot use functions such as GetRecord, GetRow, and so on, which rely on context, without specifying more context.

Activate PeopleCode can only be associated with pages.

This event is valid only for pages that are defined as standard or secondary. This event is not supported for subpages.

Note: If your application uses the MessageBox built-in function in the Activate event with a message from the message catalog that's defined as type Error, Warning or Cancel, all component processing stops with an error message to that effect. If the message has a type of Message, processing does not stop.

FieldChange Event

Use FieldChange PeopleCode to recalculate page field values, change the appearance of page controls, or perform other processing that results from a field change other than data validation. To validate the contents of the field, use the FieldEdit event.

See FieldEdit Event.

The FieldChange event applies to the field and row that just changed.

FieldChange PeopleCode is often paired with RowInit PeopleCode. In these RowInit/FieldChange pairs, the RowInit PeopleCode checks values in the component and initializes the state or value of page controls accordingly. FieldChange PeopleCode then rechecks the values in the component during page execution and resets the state or value of page controls.

To take a simple example, suppose you have a derived/work field called PRODUCT, the value of which is always the product of page field A and page field B. When the component is initialized, you would use RowInit PeopleCode to initialize PRODUCT equal to A × B when the component starts up or when a new row is inserted. You could then attach FieldChange PeopleCode programs to both A and B which also set PRODUCT equal to A × B. Whenever a user changes the value of either A or B, PRODUCT is recalculated.

FieldChange PeopleCode can be associated with record fields and component record fields.

FieldDefault Event

The FieldDefault PeopleCode event enables you to programmatically set fields to default values when they are initially displayed. This event is initiated on all page fields as part of many different processes; however, it triggers PeopleCode programs only when the following conditions are all True:

  • The page field is still blank after applying any default value specified in the record field properties.

    This is True if there is no default specified, if a null value is specified, or if a 0 is specified for a numeric field.

  • The field has a FieldDefault PeopleCode program.

In practice, FieldDefault PeopleCode normally sets fields by default when new data is being added to the component; that is, in Add mode and when a new row is inserted into a scroll area.

If a field value is changed, whether through PeopleCode or by a user, the IsChanged property for the row is set to True. The exception to this is when a change is done in the FieldDefault or FieldFormula events. If a value is set in FieldDefault or FieldFormula, the row is not marked as changed.

At save time, all newly inserted and changed rows are written to the database. All newly inserted but not changed rows are not written to the database.

You must attach FieldDefault PeopleCode to the field where the default value is being populated.

Note: An error or warning issued from FieldDefault PeopleCode causes a runtime error.

FieldDefault PeopleCode can be associated with record fields and component record fields.

FieldEdit Event

Use FieldEdit PeopleCode to validate the contents of a field, supplementing standard system edits. If the data does not pass the validation, the PeopleCode program should display a message using the Error statement, which redisplays the page, displaying an error message and turning the field red.

To permit the field edit but alert the user to a possible problem, use a Warning statement instead of an Error statement. A Warning statement displays a warning dialog box with OK and Explain buttons. It permits field contents to be changed and continues processing as usual after the user clicks OK.

If the validation must check for consistency across page fields, then use SaveEdit PeopleCode instead of FieldEdit.

The FieldEdit event applies to the field and row that just changed.

FieldEdit PeopleCode can be associated with record fields and component record fields.

FieldFormula Event

The FieldFormula event is not currently used. Because FieldFormula PeopleCode initiates in many different contexts and triggers PeopleCode on every field on every row in the component buffer, it can seriously degrade application performance. Use RowInit and FieldChange events rather than FieldFormula.

If a field value is changed, whether through PeopleCode or by a user, the IsChanged property for the row is usually set to True. However, if a value is set in FieldDefault or FieldFormula, the row is not marked as changed.

At save time, all newly inserted and changed rows are written to the database. All newly inserted but not changed rows are not written to the database.

Note: In PeopleSoft Pure Internet Architecture, if a user changes a field but that field has nothing to cause a trip to the server, then default processing and FieldFormula PeopleCode do not run. They only run when another event causes a trip to the server.

As a matter of convention, FieldFormula is now often used in FUNCLIB_ (function library) record definitions to store shared functions. However, you can store shared functions in any PeopleCode event.

FieldFormula PeopleCode is only associated with record fields.

ItemSelected Event

The ItemSelected event is initiated whenever a user selects a menu item from a pop-up menu. In pop-up menus, ItemSelected PeopleCode executes in the context of the page field from where the pop-up menu is attached, which means that you can freely reference and change page fields, just as you could from a button.

Note: This event, and all its associated PeopleCode, does not initiate if run from a component interface.

ItemSelected PeopleCode is only associated with pop-up menu items.

PostBuild Event

The PostBuild event is initiated after all the other component build events have been initiated. This event is often used to hide or unhide pages. It is also used to set component variables.

PostBuild PeopleCode is only associated with components.

PreBuild Event

The PreBuild event is initiated before the rest of the component build events. This event is often used to hide or unhide pages. It is also used to set component variables.

Note: If a PreBuild PeopleCode program issues an error or warning, the user is returned to the search page. If the search record has no keys, a blank component page appears.

Also use the PreBuild event to validate data entered in a search page after a prompt list is displayed. For example, after a user selects key values on a search, the PreBuild PeopleCode program runs, catches the error condition, and issues an error message. The user receives and acknowledges the error message. The component is canceled (because of the error), and the user is returned to the search page. PreBuild PeopleCode is only associated with components.

PrePopup Event

The PrePopup event is initiated just before the display of a pop-up menu.

You can use PrePopup PeopleCode to control the appearance of the pop-up menu.

Note: This event, and all its associated PeopleCode, does not initiate if run from a component interface.

PrePopup PeopleCode can be associated with record fields and component record fields.

RowDelete Event

The RowDelete event is initiated whenever a user attempts to delete a row of data from a page scroll area. Use RowDelete PeopleCode to prevent the deletion of a row (using an Error or Warning statement) or to perform any other processing contingent on row deletion. For example, you could have a page field called Total on scroll area level zero whose value is the sum of all the Extension page fields on scroll area level one. If the user deleted a row on scroll area level one, you could use RowDelete PeopleCode to recalculate the value of the Total field.

The RowDelete event triggers PeopleCode on any field on the row of data that is being flagged as deleted.

Note: RowDelete does not trigger programs on derived/work records.

RowDelete PeopleCode can be associated with record fields and component records.

Deleting All Rows from a Scroll Area

When the last row of a scroll area is deleted, a new, dummy row is automatically added. As part of the RowInsert event, RowInit PeopleCode is run on this dummy row. If a field is changed by RowInit (even if it’s left blank), the row is no longer new, and therefore is not reused by any of the ScrollSelect functions or the Select method. In this case, you may want to move your initialization code from the RowInit event to FieldDefault.

RowInit Event

The RowInit event is initiated the first time that the Component Processor encounters a row of data. Use it to set the initial state of component controls during component build processing and row insert processing. The RowInit event also occurs after a Select or SelectAll Rowset method, or a ScrollSelect or related function, is executed.

Note: Generally, if none of the fields in the new row are changed after the row is inserted (either by a user pressing Alt+7 or programmatically) when the page is saved, the new row is not inserted into the database. However, if the ChangeOnInit rowset class property is set to False, you can set values for fields a new row in RowInsert or RowInit PeopleCode, and the row will not be saved.

RowInit is not field-specific. It triggers PeopleCode on all fields and on all rows in the component buffer.

Do not use Error or Warning statements in RowInit PeopleCode. They cause a runtime error.

RowInit PeopleCode is often paired with FieldChange PeopleCode. In these RowInit/FieldChange pairs, the RowInit PeopleCode checks values in the component and initializes the state or value of page controls accordingly. FieldChange PeopleCode then rechecks the values in the component during page execution and resets the state or value of page controls.

For a simple example, suppose you have a derived/work field called PRODUCT, the value of which is always the product of page field A and page field B. When the component is initialized, use RowInit PeopleCode to initialize PRODUCT equal to A × B when the component starts up or when a new row is inserted. You could then attach FieldChange PeopleCode programs to both A and B, which also sets PRODUCT equal to A × B. Whenever a user changes the value of either A or B, PRODUCT is recalculated.

RowInit PeopleCode can be associated with record fields and component records.

RowInit Exceptions

In certain rare circumstances, the Component Processor does not run RowInit PeopleCode for some record fields. The Component Processor runs RowInit PeopleCode when it loads the record from the database. However, in some cases, the record can be initialized entirely from the keys for the component. When this happens, RowInit PeopleCode is not run.

For RowInit to not run, the following must all be True:

  • The record is at level zero.

  • Every record field that is present in the data buffers is also present in the keys for the component.

    The Component Processor determines if the field is required by the component. In practice, this usually means that the field is associated with a page field, possibly hidden, for some page of the component. It could also mean that the field is referenced by some PeopleCode program that is attached to an event on some other field of the component.

  • Every record field that is present in the data buffers is display-only.

RowInit not running is not considered to be an error. The purpose of RowInit PeopleCode is to complete initialization of data on the row after it has been read from the database. Because the data in this special circumstance is coming from the keylist, it was already initialized correctly by whatever processing produced the keylist. More general initialization of the component should be done in PostBuild PeopleCode, not RowInit.

RowInsert Event

When a user adds a row of data, the Component Processor generates a RowInsert event. You should use RowInsert PeopleCode for processing specific to the insertion of new rows. Do not put PeopleCode in RowInsert that already exists in RowInit, because a RowInit event always initiates after the RowInsert event, which will cause your code to be run twice.

Note: Generally, if none of the fields in the new row are changed after the row has been inserted (either by a user pressing Alt+7 or programmatically), when the page is saved, the new row is not inserted into the database. However, if the ChangeOnInit rowset class property is set to False, you can set values for fields a new row in RowInsert or RowInit PeopleCode, and the row won't be saved.

The RowInsert event triggers PeopleCode on any field on the inserted row of data.

Do not use a warning or error in RowInsert.

You can prevent a user from inserting rows into a scroll area by selecting the No Row Insert check box in the scroll bar’s page field properties, as shown in the following illustration. However, you cannot prevent row insertion conditionally.

Image: Setting row insert properties in page field properties for a scroll bar

This example illustrates the fields and controls on the Setting row insert properties in page field properties for a scroll bar. You can find definitions for the fields and controls later on this page.

Setting row insert properties in page field properties for a scroll bar

Note: RowInsert does not trigger PeopleCode on derived/work fields.

RowInsert PeopleCode can be associated with record fields and component records.

RowSelect Event

The RowSelect event is initiated at the beginning of the component build process in any of the update action modes (Update, Update/Display All, Correction). RowSelect PeopleCode is used to filter out rows of data as they are being read into the component buffer. This event also occurs after a ScrollSelect or related function is executed.

A DiscardRow function in RowSelect PeopleCode causes the Component Processor to skip the current row of data and continue to process other rows. A StopFetching statement causes the Component Processor to accept the current row of data, and then stop reading additional rows. If both statements are executed, the program skips the current row of data, and then stops reading additional rows.

PeopleSoft applications rarely use RowSelect, because it's inefficient to filter out rows of data after they've already been selected. Instead, screen out rows of data using search record views and effective-dated tables, which filter out the rows before they're selected. You could also use a ScrollSelect or related function to programmatically select rows of data into the component buffer.

In previous versions of PeopleTools, the Warning and Error statements were used instead of DiscardRow and StopFetching. Warning and Error statements still work as before in RowSelect, but their use is discouraged.

Note: In RowSelect PeopleCode, you can refer to record fields only on the record that is currently being processed. This event, and all its associated PeopleCode, does not initiate if run from a component interface.

RowSelect PeopleCode can be associated with record fields and component records.

SaveEdit Event

The SaveEdit event is initiated whenever a user attempts to save the component. You can use SaveEdit PeopleCode to validate the consistency of data in component fields. Whenever a validation involves more than one component field, you should use SaveEdit PeopleCode. If a validation involves only one page field, use FieldEdit PeopleCode.

SaveEdit is not field-specific. It triggers associated PeopleCode on every row of data in the component buffers except rows flagged as deleted.

An Error statement in SaveEdit PeopleCode displays a message and redisplays the component without saving data. A Warning statement enables the user to click OK and save the data, or to click Cancel and return to the component without saving.

Use the SetCursorPos function to set the cursor position to a specific page field following a warning or error in SaveEdit, to show the user the field (or at least one of the fields) that is causing the problem. Make sure to call SetCursorPos before the error or warning, because these may terminate the PeopleCode program.

SaveEdit PeopleCode can be associated with record fields and components.

SavePostChange Event

After the Component Processor updates the database, it initiates the SavePostChange event. You can use SavePostChange PeopleCode to update tables not in your component using the SQLExec built-in function.

An error or warning in SavePostChange PeopleCode causes a runtime error. Avoid errors and warnings in this event.

The system issues a SQL Commit statement after SavePostChange PeopleCode completes successfully.

If you are executing Workflow PeopleCode, keep in mind that if the Workflow PeopleCode fails, SavePostChange PeopleCode is not executed. If your component has both Workflow and SavePostChange PeopleCode, consider moving the SavePostChange PeopleCode to SavePreChange or Workflow.

If you are doing messaging, your Publish PeopleCode should go into this event.

SavePostChange does not execute if there is an error during the save. For example, if there is a data conflict error because another user updated the same data at the same time, SavePostChange does not execute.

Important! Never issue a SQL Commit or Rollback statement manually from within a SQLExec function. Let the Component Processor issue these SQL commands.

SavePostChange PeopleCode can be associated with record fields, components, and component records.

SavePreChange Event

The SavePreChange event is initiated after SaveEdit completes without errors. SavePreChange PeopleCode provides one final opportunity to manipulate data before the system updates the database; for instance, you could use SavePreChange PeopleCode to set sequential high-level keys. If SavePreChange runs successfully, a Workflow event is generated, and then the Component Processor issues appropriate Insert, Update, or Delete SQL statements.

SavePreChange PeopleCode is not field-specific: it triggers PeopleCode on all fields and on all rows of data in the component buffer.

SavePreChange PeopleCode can be associated with record fields, components, and component records.

SearchInit Event

The SearchInit event is generated just before a search, add, or data-entry dialog box is displayed. SearchInit triggers associated PeopleCode in the search key fields of the search record. This enables you to control processing before a user enters values for search keys in the dialog box. In some cases, you may want to set the value of the search dialog fields programmatically. For example, the following program in SearchInit PeopleCode on the component search key record field EMPLID sets the search key page field to the user’s employee ID, makes the page field unavailable for entry, and enables the user to modify the user’s own data in the component:

EMPLID = %EmployeeId;
Gray (EMPLID);
AllowEmplIdChg(True);

You can activate system defaults and system edits in the search page by calling SetSeachDefault and SetSearchEdit in SearchInit PeopleCode. You can also control the behavior of the search page, either forcing it to appear even if all the required keys have been provided, or by skipping it if possible, with the SetSeachDialogBehavior function. You can also force search processing to always occur by selecting the Force Search Processing check box in the component properties in PeopleSoft Application Designer.

Note: This event, and all its associated PeopleCode, does not initiate if run from a component interface.

SearchInit PeopleCode can be associated with record fields on search records and prompt table records and on component search records and component prompt table records.

SearchInit with Prompt Dialogs

Beginning with PeopleTools 8.50, you can put PeopleCode on the SearchInit and SearchSave events on the search keys of prompt table records. SearchInit and SearchSave events will only execute if the Allow Search Events for Prompt Dialogs checkbox was selected for the search key’s record field properties in Application Designer. By default Allow Search Events for Prompt Dialogs is off.

Note: Search processing with prompt dialogs can affect performance. Oracle recommends that you limit the use of PeopleCode with prompt dialogs.

 

SearchInit PeopleCode Function Restrictions

You cannot use the following functions in SearchInit PeopleCode:

  • DoModal

  • DoModalComponent

  • Transfer

  • TransferExact

  • TransferNode

  • TransferPage

  • TransferPortal

SearchSave Event

SearchSave PeopleCode is executed for all search key fields on a search, add, or data-entry dialog box after a user clicks Search. This enables you to control processing after search key values are entered, but before the search based on these keys is executed. A typical use of this feature is to provide cross-field edits for selecting a minimum set of key information. This event is also used to force a user to enter a value in at least one field, even if it’s a partial value, to help narrow a search for tables with many rows.

Note: SearchSave is not initiated when values are selected from the search list. To validate data entered in the search page, use the Component PreBuild event.

You can use Error and Warning statements in SearchSave PeopleCode to send the user back to the search page if the user entry does not pass validations implemented in the PeopleCode.

Note: This event, and all its associated PeopleCode, is not initiated if run from a component interface.

SearchSave PeopleCode can be associated with record fields and component search records.

Note: Do not use the %Menu system variable in this event. You may get unexpected results.

SearchSave with Prompt Dialogs

Beginning with PeopleTools 8.50, you can put PeopleCode on the SearchInit and SearchSave events on the search keys of prompt table records. SearchInit and SearchSave events will only execute if the Allow Search Events for Prompt Dialogs checkbox is selected for the search key’s record field properties in Application Designer. By default Allow Search Events for Prompt Dialogs is off.

Note: Search processing with prompt dialogs can affect performance. Oracle recommends that you limit the use of PeopleCode with prompt dialogs.

Workflow Event

Workflow PeopleCode executes immediately after the SavePreChange event and before the database update that precedes the SavePostChange event. The Workflow event segregates PeopleCode related to workflow from the rest of the application’s PeopleCode. Only PeopleCode related to workflow (such as TriggerBusinessEvent) should be in workflow programs. Your program should deal with the Workflow event only after any SavePreChange processing is complete.

Workflow PeopleCode is not field-specific: it triggers PeopleCode on all fields and on all rows of data in the component buffer.

WorkFlow PeopleCode can be associated with record fields and components.