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;
|
·
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;
|
·
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.
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
|
