A form simply allows you to work visually with the data in the database. It is a representation of the data in the database tables, a collection of objects that yields a graphic interface to the data. Every form, no matter how simple, contains the following pieces: ? At least one block ? At least one item ? At least one canvas ? At least one window Most Oracle Forms 10g have multiples of each of these objects, but the basics are the same, no matter how simple or complex the form.In addition to the basic objects in a form, the toolkit supports a wide variety of widgets and interface items to build the user experience: buttons, toolbars, check boxes, radio buttons, even Java-bean controls. PL/SQL code behind these objects (and in the database) controls validation and behavior in the form. Data Blocks Blocks are the form elements that connect the displayed items on the screen to the database. The block itself is never seen when a form is running; only the items that it contains are displayed on the canvas. pic] Figure 3-1: A graphical description of database tables and Oracle Forms 10g canvases Blocks can be based on single database tables, multiple tables (via a view), and even the returned values from a PL/SQL package. Blocks can also be created that are not connected to (not bound) to the database at all. These are commonly called Control Blocks or non-base table blocks (NBTs). Control Blocks can be used to hold working variables, reference values, or any other data that is used or displayed within the Form.When a block is associated with tables in the database, Oracle Forms 10g handles the standard DML functions automatically. Select, Insert, Update, and Delete are supported for these blocks without having to write additional code. When the block is based on a view, limited ability to perform DML is supported (based on the rules for updatable views). When the block is based on PL/SQL code, or when you want to perform nonstandard functions when the user attempts to update or delete items in the form, then PL/SQL code can be written to perform the desired action and override the standard DML functions.For example, if a user deletes a record on screen, but the system requires that items never be deleted (they must be marked inactive instead), then the delete function can be “replaced” by PL/SQL code to set the appropriate flags invisibly to the user. For the standard behavior, however, no code is required. Oracle Forms 10g handles the interaction automatically. Items and Data Items Items are the form elements that connect the form to a column in the database table (or, as noted in the preceding section, “Data Blocks,” a returned value from PL/SQL). Items can only be created within blocks.They are the pieces of a block that are seen when the form is running. The items may be bound to the database, in which case they represent a column in the table or view being bound, or a value returned by a PL/SQL package. Or, the item may be a calculated value or reference value from a Control Block. Cursor Navigation Cursor navigation at run time is controlled by the orientation of the data blocks and items set at design time in the Object Navigator. By default, the cursor goes to the first item on the first block of the form, and then moves through each block and item in the form.By rearranging the data blocks and items, the navigation sequence at run time can be controlled. There are other ways to control navigation: programmatically or by hard-coding the sequence of items. It is always preferable to use the physical ordering of item and blocks to control navigation. Finally, you can specify what behavior should occur when you reach the last item in a record. The cursor can return to the first item in the same record, can move to the next record, or can move to the next block in the form.Blocks can be displayed on the canvas either as a single-record-per-screen (form layout), or with multiple records displayed (tabular format). Which layout you use depends on the kind of data displayed and the functionality of the forms. For example, maintaining a list of codes is more easily done when the data is displayed in multiple rows, spreadsheet-fashion. Working with customer data, on the other hand, may require showing more details, and a forms-type layout is more readable. Master-Detail Relationships Oracle Forms 10g easily manages the concept of parent-child relationships between blocks.A parent-child (or Master-Detail) relationship between tables in the database, such as a customer having many locations, or an order having many lines, is usually represented by foreign-key relationships between the tables. However, a master detail relationship does not require that this database relationship exist. Within Oracle Forms 10g, the relationship between the master and detail blocks ensures that the detail block displays only those records that are associated with the current master record, and coordinates querying, data entry, and deletion between the blocks.The detail block must be created after the master block is created (the easiest way to do this is to use the wizard, which will allow you to set up the relationship automatically). An important component of the relationship is how the blocks remain coordinated. Forms can either automatically query the detail information every time the master record is viewed, or querying the detail blocks can be deferred until they are needed and then they’re either automatically queried on first use, or manually queried via code.By far the most common master-detail relationship is one parent and one child. For example, an order header and order lines. One parent and many children is common for informational forms, such as customer information which has various subtables of information such as addresses, shipping and billing information, and contacts. It is uncommon to have one child record belong to more than one parent record. This situation requires that you manipulate the auto-generated triggers for master-detail relationships. Canvases, Windows, and ViewsCanvases, windows, and views are the components of Forms that the user sees when the form is run; each is a different “layer” in the display of the form on screen (Figure 3-2). The canvas is the object on which the GUI is drawn, the “background” of the form. All the other visible objects in the form are drawn on the canvas. The window is the frame through which the canvas is seen. The View is the object that controls how much of the canvas can be seen at any given time. [pic] Figure 3-2: A graphical representation of windows, views, canvases, and itemsThe canvas can be any size (within reason), while the window controls the ultimate size of the interface. It controls how much of the canvas can be seen at any one time. If the canvas is larger than the window, then only what can fit into the window will be visible. Windows When a Forms application is displayed, it is enclosed in a master window, called the Multiple Document Interface (MDI) window. This is the outer “container” window for the application; other windows will open within the MDI. There are two types of windows within Forms: a document window and a dialog indow. The document window is the “standard” window of an application, while a dialog window is a “pop-up” window that is independent of the application and can be moved outside of the MDI window. Dialog windows have an additional property that controls their behavior. The modal property determines if the dialog window has a synchronous or an asynchronous display. A modal window must be explicitly dismissed before the user can return to another window. A nonmodal window allows the user to switch back and forth between open windows.Error messaging and confirmation dialog windows are usually modal windows: processing stops until the user acknowledges the message. An application may have a single window into which all canvases are displayed, or it may have multiple windows. Some forms display each canvas in the same window, while others display each canvas in its own window and have multiple popup displays of different sizes. There is no practical limit to the number of windows in a form. In practice, however, there are rarely more than five to ten.