0854-0857

Previous Table of Contents Next

Page 854

Figure 35.12.
Sample form
demonstrating custom
properties.

Implementing Triggers and Program Units

You can further customize Oracle Forms applications by developing PL/SQL procedures and functions called triggers. These triggers are attached to specific activities in the form called events. Events typically are defined as before (PRE-FORM, PRE-QUERY, PRE-INSERT), after (POST-FORM, POST-QUERY, POST-INSERT), or during (WHEN-NEW-FORM-INSTANCE, WHEN-BUTTON-PRESSED) common database activities. Additionally, you can associate triggers with certain keyboard activities (for backward compatibility with character-based applications), although the trend is to minimize key triggers.

The Customer Maintenance form shown in Figure 35.13 uses a PRE-INSERT trigger to determine a unique customer number based on a sequence generator. Additionally, triggers are defined for the buttons at the bottom of the form.

To construct this form, create a block for the CUSTOMERS table using a form style in the block layout definition. Arrange the items and boilerplate objects as shown in the figure, and using the button tool, create three buttons as shown on the screen. (These buttons will be labeled as PUSH_BUTTONx.) Using the Size Objects and Align Objects tools in the Arrange menu, position and size the form objects to appear as shown.

Now, define the object properties as needed by defining the window and canvas sizes and titles. Next, because the customer number should be protected from update, change the Update Allowed and Navigable properties for the CUST_NO item to False. Modify the label properties for the buttons to reflect the text that is shown in the figure.

At this point, you can add the additional processing logic to the form. First, select the triggers group directly below the CUSTOMERS block in the Object Navigator. Click the Add Object button and a list appears with the names of all allowable triggers that can be built for the form.

Page 855

The trigger to be built determines the customer number for a new customer prior to insert based on the database sequence generator. While the list is displayed, either use the scrollbar to find the PRE-INSERT trigger or type the trigger name into the input box.

Figure 35.13.
Customer Maintenance
form.

NOTE

Generally , lists in Oracle Forms use an algorithm to narrow a list as keys are typed. In this case, after you type P and R, the list shows all PRE-x triggers and the input line types ahead because no other triggers exist that begin with those letters . Type an I and the PRE-INSERT trigger is the only trigger in the list.

The PL/SQL editor (shown in Figure 35.14) appears, indicating the trigger level and the name of the trigger with an area that can be used to enter the trigger procedure as shown. Once the text is entered, click the Compile button to make sure that there are no code errors and then click the Close button to complete the trigger definition. Note the colon used to reference form fields. You can use other buttons to revert to the version prior to the last close or compilation, to create a new trigger, or to delete the existing trigger.

Finally, you should create WHEN-BUTTON-PRESSED triggers for the three buttons that were created on the form canvas as follows :

 Save:     begin           commit_form;      end; Clear:    begin           clear_form;      end; Exit:     begin           do_key (`EXIT_FORM');      end; 

Page 856

Figure 35.14.
PL/SQL editor for
trigger creation.

The first two triggers use standard built-in procedures, whereas the third uses the DO_KEY built-in procedure to simulate pressing the Exit key.

NOTE

The Exit key is defined by the keyboard mapping for your display device. On the IBM PC keyboard, this usually defaults to the Esc key but can be modified using Oracle Terminal. To view the actual key mapping during Oracle Forms runtime, type Ctrl+K or select Show Keys from the Help menu in the form.

Whenever a screen button is used to perform the same function that would be performed by pressing a specific key, it is generally a good practice to use the DO_KEY built-in procedure. You can code any special logic that needs to be performed prior to exiting the form in a KEY-EXIT trigger to ensure consistency. Additionally, you can write a trigger to call a user -defined program unit. For example, if the Customer Maintenance form changes the credit limit for a customer, an acceptance letter should be sent to the customer. The POST-COMMIT trigger should be written as follows:

 begin      if :customers.cust_credit_limit > 0 and :customers.old_credit is null then         print_confirmation_letter (:customers.cust_no);      end if; end; 

The print_confirmation_letter procedure is then created as a program unit in the form. The actual logic for this procedure is discussed in Chapter 38, "Developer/2000 Integration," in the section describing the integration of Oracle Forms and Oracle Reports.

Page 857

Using Record Groups and Lists of Values for Data Validation

A record group is an internal structure that is analogous to a table in memory. Record groups contain columns and rows with data based on a structure defined by a query or column definition. Uses of record groups include parameters, structured arrays, and validation entities. This last use of record groups is demonstrated in the Item Maintenance form shown in Figure 35.15.

Figure 35.15.
Item Maintenance
form.

To build this form, start with a default block for the items table using the form style layout. Next, change the Displayed Canvas to <Null> and the Displayed property to False for the ITEM_PL_ID, ITEM_PC_ID, ITEM_PROD_NO, ITEM_CP_NO, and ITEM_SIZE_CODE items. These items are hidden from view and are updated by the list of values validations that are constructed for this form. Also, make the ITEM_NO field non-updatable and non-navigable.

To make this form more user-friendly, the translations for the code fields are displayed as the input fields in the form. Using the Field tool, create five new fields as PL_NAME, PC_NAME, PROD_NAME, CP_NAME, and SIZE_DESC. Table 35.3 shows the properties for these fields.

Table 35.3. Item Maintenance description fields.

Property	Value
Canvas	ITEM_CANVAS
Displayed	True

 continues 

Previous Table of Contents Next