Page 839
Page 840
As stated in the previous chapter, Oracle Forms 4.5 is a development tool that can be used to create applications to enter, access, change, or delete data from an Oracle database in an online, form-based environment. Forms has provided many objects for developing an effective application module. Coupled with the concept of user extensibility, Forms can be used to serve virtually every online need in an Oracle database environment.
This chapter explores many of the concepts related to Oracle Forms development. The examples start with a few baby steps and gradually add enough information so that you will be able to walk on your own. With each advance in complexity, the applications become more powerful. By the end, you will be able to delve further into many advanced concepts and perhaps add innovations of your own.
Oracle Forms 4.5 operates in a graphical user interface (GUI) environment such as Microsoft Windows 3.x. The primary tools used to develop customized forms are the Object Navigator, the Layout Editor, and the object property sheets. In addition to online forms, Oracle Forms 4.5 is also used to create and maintain application menus and program unit libraries.
The Object Navigator (shown in Figure 35.1) presents all the elements that combine to create an Oracle Forms application module. You can manipulate these elements (or objects) using the iconic buttons and menu options. Within the Object Navigator, the application components are presented in a hierarchical outline format indicating the organization of the form elements. The individual element groupings are described in the following subsections.
Figure 35.1.
The Oracle Forms
Object Navigator and
property sheets.
Page 841
Triggers are PL/SQL functions that are executed based on some specific activity or condition in the form. These activities, called events, are the foundation of Oracle Forms' user extensibility feature. Although many of the trigger events perform a particular default function, you can write a trigger to disable, modify, or enhance the default processing capabilities associated with the event. You can define triggers at the form, block, record, or individual field level. In addition, a trigger can cause another trigger to "fire," as well as execute, another related program unit.
Alerts provide additional information or other messages that require response or acknowledgment from the user. An alert can contain one to three buttons that you can use to define the action the user wants to execute based on the condition.
Libraries are special Oracle Forms modules that can be defined to contain reusable procedures and functions. By attaching program unit libraries to a form, you can maintain the program code in a single file rather than in each individual form module. Libraries help to ensure the quality of an application by checking that all modules follow the same set of business rules.
A block in a form generally corresponds to an individual entity (table, view, or snapshot) in the database. Additionally, you can create blocks that do not correspond to any table. These blocks, called non-base table blocks, usually hold generic control information, such as query criteria, counters, conditional indicators, and other information that might relate to more than one record or activity. (Blocks that relate to an entity are referred to as base table blocks.)
Items (which are not shown in Figure 35.1) are grouped in the Object Navigator within their respective blocks. An item corresponds to a single data element or field. These items can contain database columns or can be used as containers for other related data.
Relationships (not shown in Figure 35.1) are defined according to how the separate blocks in a form relate to each other. Typically in a multiple block form, one block is defined as the primary or master table, and the other blocks display detail information associated with the current record in the master block. An example of a master-detail form is a customer record application where the master block shows the customer name and address and the detail block displays the history of purchases made by the customer in multiple records.
Page 842
A canvas is the virtual structure where the form objects are laid out. For the most part, canvases are defined as either content or stacked canvases. A content canvas is displayed in its entirety within the form window. Whenever a content canvas is first displayed, any other canvases are hidden in the window. A stacked canvas, on the other hand, displays "on top" of any existing canvases within the form window. In addition to these two canvas types, a third canvas type was included in Forms 4.5: a button bar canvas. A button bar canvas appears on top of all displayed canvases and is usually used to contain iconic buttons for user commands. A special null canvas exists to contain objects that are not displayed.
An editor is a window for viewing and maintaining large data fields. These fields are sometimes included for the entry of user comments or other information that does not normally fit in a displayed item.
LOVs (also called lists of values) provide the user with a list of valid entries for a field. A list of values presents data contained within an object called a record group whereby the user selects one value from the list to populate a form item. You can also use the list of values to validate user input to ensure that a valid value is entered.
An object group is a special mechanism for packaging several form objects into a container, which can then be used in other forms with a minimum of programming. Once you create an object group in a form, you can copy any of the form objects into the object group. For example, a form can contain a secondary page showing a scheduling template. You can copy the components of this submodule to the object group and other forms can reference the object group, which behaves as if it were part of the second form itself. This is another feature of Forms that promotes the object-oriented approach while assuring quality through consistency.
You can define parameters for a form to provide a startup input for the form. Typically, parameters pass values from one form to a newly called form in a multiple-form application. Prior to the Developer/2000 tools, the only way to pass values between forms was through the use of global variables that tended to consume available memory. Although global variables are still available, you should use parameters in cases where the data is specific to the individual forms rather than universal to all forms in an application.
Program units are PL/SQL procedures and functions that the form triggers can call. A program unit is equivalent to the third-generation programming concept of subroutines. A typical