Forms functionality is driven by user events (such as pressing a key) and navigation events (such as the cursor about to enter/leave a field). These events are identified by triggers in a form. These triggers fall into several groups:
KEY – Fires when the corresponding key is pressed
PRE – Fires prior to an event
WHEN – Fires when an event occurs
ON – Replaces default event processing
POST – Fires after an event
These triggers include events such as:
- PRE and POST triggers for the form block, row, and item.
- PRE and POST triggers for row inserts, updates, and deletions.
- WHEN triggers fire as a direct result of an event such as the user clicking on a button (WHEN-BUTTON-PRESSED) or the cursor navigating to a new item and readying for user input (WHEN-NEW-ITEM-INSTANCE).
- Keys the user can press on their keyboard like the Tab button (KEY-NEXT-ITEM) or F10 (KEY-COMMIT).
- ON triggers fire when an event occurs. For example, ON-MESSAGE fires when forms is about to issue a message. This gives the developer an opportunity to trap and replace particular messages with custom messages.
By adding PL/SQL code to a trigger you can:
- Alter the way a trigger would ordinarily work. For instance, by creating a KEY-ENTQRY on a field with: null; you will prevent the user from pressing F8.
- Supplement the way something works – for instance by creating a KEY-DELREC trigger on a block with code that asks the user if they “really” want to delete that record before issuing the delete_record;.
If you create a KEY-EXEQRY on a field with: null; then you will prevent the user from pressing F8 while the cursor is in that field. If, instead, you attach the same trigger to a block, then you will prevent the user from pressing F8 while the cursor is anywhere in that block. If, instead, you attach the same trigger to the form, then you will prevent the user from pressing F8 anywhere within the form.
You can override high level triggers at a lower level. For example, if you have disabled F7 at the form level, you can add a KEY-ENTQRY to a block with: enter_query; that will allow the user to press F7 to enter a query while the cursor is in that block. This means that F7 will work in that block but nowhere else in the form.
A most basic concept in a form is blocks. Blocks are basically comprised of 2 types:
- Control block – A block not associated with a table. This block is usually a single row block that has no interaction with the database.
- Base table block – this is associated with a table. You do not have to code any SQL statements! Forms will automatically:
A. Query rows of data from the table (execute_query)
B. Insert a new row below the current row (create_record)
C. Delete the current row (delete_record)
D. Update rows (by the user typing values on a queried row)
E. Handle row locking
F. Make all these database changes permanent at commit time
A canvas is an object that can be displayed on the screen. The canvas may contain buttons, graphics, display items and text items.
The canvas may be smaller or larger than the screen size. One canvas may be stacked on top of another canvas so that the user might see several canvases at the same time.
A large canvas might only be partially visible to the user. This is known as a “view” of the canvas.
If the cursor navigates to an enterable
item on a canvas, then the canvas becomes
visible to the user. However, when the
cursor leaves the items on the canvas,
the canvas will not automatically be
hidden from view unless another canvas