Peoplecode event and Functions

Event / Abbr	Function
Searchlnit	·         SearchInit PeopleCode is performed before the search page is displayed. ·         User SearchInit to control processing before a user enters values in the search page. ·         Place SearchInit PeopleCode on search key fields or alternate search key fields on a search record or component search record. ·         Do not place errors or warnings in SearchInit
Search Save	·         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. ·         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. ·         Do not use the %Menu system variable in this event. You may get unexpected results.
RowSelect	·         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 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. ·         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. ·         RowSelect PeopleCode can be associated with record fields and component records.
PreBuild	·         The PreBuild event fires before the rest of the component build events. It is only associated with components. ·         The PreBuild event is also used to validate data entered in the search dialog, after a prompt list is displayed. ·          It is used to hide or unhide pages
Field Default	·         For FieldDefault to trigger, there are two conditions that need to be satisfied: One is obviously having some PeopleCode written in this event. Second one is that, the page field should have no value even after applying default values (if any) specified in the record field properties. A point to note is that, the page field is consider blank if a zero is specified as default for a numeric field or a null is specified. ·         Default values set using FieldDefault does not mark the row as changed and such rows are not written back to the database during save. ·         Another point to note is that the you can’t issue an Error or a Warning from within this event. This would cause a runtime error. ·         FieldDefault PeopleCode can be associated with record fields and component record fields.
Field Formula	·         FieldFormula is mainly used to record definitions to store shared functions. It can be used for other functionality too but RowInit and FieldChange are preferred methods. ·         The FieldFormula event is not currently used (for setting values, hiding fields etc). 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. ·         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. ·         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.
Rowlnit	The RowInit event is initiated the first time that the Component Processor encounters a row of data. This occurs during component build processing and row insert processing. It also occurs after a Select or SelectAll Rowset method, or a ScrollSelect or related function, is executed. Code Example in RowInit If %Page = Page.PAGE_NAME Then       RECORD_WRK.CALC_FIELD = RECORD1.FIELD1 * RECORD2.FIELD2; End-If; ·         Do not use Error or Warning statements in RowInit PeopleCode, these cause a runtime error. ·         RowInit is often written together with FieldChange event. In the above example, the value of RECORD_WRK.CALC_FIELD is shown as the product of RECORD1.FIELD1 and RECORD1.FIELD2. Generally, similar code is written in FIELDCHANGE event of RECORD1.FIELD1 and RECORD1.FIELD2 so that value of RECORD_WRK.CALC_FIELD is updated whenever the field value changes. ·         RowInit is not field-specific. That is, It triggers PeopleCode on all fields and on all rows in the component buffer. In the above example, the above code can be written in ROWINIT of either of FIELD1 or FIELD2 not both. Although you can write code like this in PAGE ACTIVATE which we will discuss later. ·         RowInit PeopleCode can be associated with record fields and component records.
PostBuild	The PostBuild event fires only after all the other component build events have been fired. This event is often used to hide or unhide pages. It’s also used to set component variables. ·         Generally used to Hide/Unhide Pages ·         Used to set Global & Component Variables ·         This is associated with component. ·         Used to Calculate values and set display characteristics of an object. Although both prebuild and post build are generally used for same functionality, as explained before prebuild fires before the component events and post build fires after the component event. Prebuild does have access to component buffer but Post build does.
Activate	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. ·         Every Page has it’s own Activate Event ·         This event is not supported for subpages. ·         Effectively eliminates need to write Page Specific RowInit code. For Example, If Page1, hide some field, Page Hide other field etc. ·         This event is valid only for pages that are defined as standard or secondary.
FieldEdit	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. ·         Performs after the field value has been changed and the new value of the field satisfies the standard system edits (Eg. Prompt Table Edit). ·         Used to validate Content of the field. ·         Only fires on specific field or row that has has Changed. ·         Associated with Record Fields and Component Record Fields.
FieldChange	The FieldChange event is triggered when is field is changed. 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. Code Example in FieldChange If %Page = Page.PAGE_NAME Then       RECORD_WRK.CALC_FIELD = RECORD1.FIELD1 * RECORD2.FIELD2; End-If; ·         Used to perform additional processing that is based on the new value of changed field. ·         FieldChange PeopleCode can be associated with record fields and component record fields. ·         FieldChange and RowInit peoplecode are often paired together. ·         Donot use this event for validations, use FieldEdit instead.
Rowlnsert	When a user adds a row of data to a scrollarea or grid, the Component Processor generates a RowInsert event. ·         Rowinit is also executed when a row is inserted, so write specific code for the inserts. If the RowInit and RowInsert code is same, the code will run twice. ·         The RowInsert event triggers PeopleCode on any field on the inserted row of data. ·         Do not use a warning or error in RowInsert. ·         RowInsert does not trigger PeopleCode on derived/work fields. ·         RowInsert PeopleCode can be associated with record fields and component records.
Row Delete	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. ·         RowDelete does not trigger PeopleCode on derived/work fields. ·         RowDelete PeopleCode can be associated with record fields and component records. ·         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.
SaveEdit	The SaveEdit event is intiated 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. ·         The component processor applies SaveEdit peoplecode to all non-deleted rows of data in the buffers & all pages in component ·         SaveEdit is better suited than FieldEdit if the validation refrences more than one field or row of data. ·         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. ·         Associated with record fields and Components. When an error message is issued in PeopleSoft(Component Processor) from the SAVEEDIT event, the cursor will not be directed to the corresponding field (value) for which the message is thrown. And the field also doesnot turn into red color as is the behaviour with the error messages issued from the FIELDEDIT event. Use SetCursorPos as shown above to set the cursor position. Here is example below written in SAVEEDIT. view source print? IF NONE(RECORD1.FIELD1) THEN   RECORD1.FIELD1.Setcursorpos(%Page);   REM To Display field in Red Color   RECORD1.FIELD1.Style = "PSERROR";   Error ("The Field is Required");  END-IF;
SavePreChange	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. ·         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. ·         Used to change display characteristics and validations ·         SavePreChange PeopleCode can be associated with record fields, components, and component records.
Workflow	·         To trigger a business event from a page, you add a PeopleCode program to the workflow event in the record definition for one of the tables to which the page writes. For example, to trigger events from the Course Request page, add Workflow PeopleCode to the TRAINING record definition; TRAINING is the record definition with which the Course Request page fields are associated. ·         If you’re triggering business events from a page that includes scrolls, add the Workflow PeopleCode to the record definition at the appropriate scroll level. If, for example, you add it to the record definition that is associated with a level one scroll area, the PeopleCode runs once for each row at that level. A Workflow PeopleCode program can reference record fields from record definitions at the same scroll level or at a lower scroll level. These rules also apply to the SaveEdit PeopleCode for Virtual Approver. ·         Workflow PeopleCode runs after the user saves the page group and before it updates the database with the saved data. More specifically, it runs after SavePreChange PeopleCode and before SavePostChange PeopleCode. Because SavePostChange PeopleCode runs after Workflow PeopleCode, it does not run if the Workflow PeopleCode fails to finish. ·         Workflow PeopleCode programs typically review the data in the saved record, then decide which business event to trigger, if any. They all include at least one use of the PeopleCode function that triggers events, or Virtual_Router, a PeopleCode library function that is associated with Virtual Approver, which uses TriggerBusinessEvent internally. The Virtual_Router PeopleCode library function is located in the FieldFormula event of the APPR_VA0_WRK.FUNCLIB_02 record field. ·         You can add the Workflow PeopleCode to any field in the record definition. For clarity, you can add it to a field that the program itself references. For example, you might add the Workflow PeopleCode that triggers an approval process to the Approval Status field.
SavePostChange	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. ·         Performs after SavePreChange and Workflow have completed successfully. SavePostChange is not executed if workflow fails or component is not saved due to any error. ·         Donot use Error and Warnings in this event ·         The system issues a SQL Commit statement after SavePostChange PeopleCode completes successfully. ·         Other than updating tables that are not in your component, it is also used to send an email , say for approval. ·         SavePostChange PeopleCode can be associated with record fields, components, and component records.
PrePopup	·         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. ·         This event, and all its associated PeopleCode, does not initiate if run from a component interface.
ItemSelected	·         PeopleTools menus are one of two types, either pop-up or standard, both of which are standalone definitions in the project hierarchy. However, you can only associate PeopleCode with menu items in pop-up menus. ·         The menu item event set consists of a single event, the ItemSelected Event. This event fires whenever an user selects a menu item from a pop-up menu. ·         Do not confuse menu item PeopleCode with PeopleCode functions related to the appearance of menu items, such as CheckMenuItem. Defining PeopleCode Pop-Up Menu Items To define a PeopleCode pop-up menu item: ·         In the open pop-up menu definition, double-click the menu item to access its properties. If you are creating a new menu item, double-click the empty rectangle at the bottom of the pop-up menu. The Menu Item Properties dialog box appears. ·         If this is a new menu item, enter a name and a label for the item. ·         Select PeopleCode from the Type group box. ·         Click OK to close the Menu Item Properties dialog box. Accessing Menu Item PeopleCode To access pop-up menu item PeopleCode: 1.    Open the pop-up menu definition. 2.    Right-click the menu item and select View PeopleCode. The PeopleCode Editor appears, displaying the associated program for that menu item, if any