Alerts Styles

An alert is a modal window that displays a message notifying the operator of some application condition. There are three styles of alerts: Stop, Caution, and Note.  Each style denotes a different level of message severity.  Message severity is represented visually by a unique icon that displays in the alert window.

Model/Modeless Windows (Difference)

A window can be either modeless or modal.  A modal window (often a dialog) requires the end user to respond before continuing to work in the current application.  A modeless window requires no such response.

You can display multiple modeless windows at the same time, and end users can navigate freely among them. Modeless windows remain displayed until they are dismissed by the end user or hidden programmatically.  You can set the Hide on Exit property for a modeless window to specify whether it should remain displayed when the end user navigates to another window. Modal windows are usually used as dialogs, and have restricted functionality compared to modeless windows. On some platforms, modal windows are "always-on-top" windows that cannot be layered behind modeless windows. The Hide on Exit property does not apply to modal windows. Modal dialog windows cannot have scroll bars

Property Class & Visual Attributes (Difference)

A property class is a named object that contains a list of properties and their settings. Once you create a property class you can base other objects on it.  An object based on a property class can inherit the setting of any property in the class that makes sense for that object. Property class inheritance is an instance of subclassing. Conceptually, you can consider a property class as a universal subclassing parent. Property classes are separate objects, and, as such, can be copied between modules as needed. Perhaps more importantly, property classes can be subclassed in any number of modules. Property class inheritance is a powerful feature that allows you to quickly define objects that conform to your own interface and functionality standards. Property classes also allow you to make global changes to applications quickly.  By simply changing the definition of a property class, you can change the definition of all objects that inherit properties from that class.

Visual attributes are the font, color, and pattern properties that you set for form and menu objects that appear in your application's interface. Visual attributes can include the following properties: Font properties, Color and pattern properties. Every interface object has a Visual Attribute Group property that determines how the object's individual visual attribute settings (Font Size, Foreground Color, etc.) are derived

Named visual attributes define only font, color, and pattern attributes; property classes can contain these and any other properties.

You can change the appearance of objects at runtime by changing the named visual attribute programmatically; property class assignment cannot be changed programmatically.

When an object is inheriting from both a property class and a named visual attribute, the named visual attribute settings take precedence, and any visual attribute properties in the class are ignored.

Property Class has triggers and Visual Attributes don’t have same.

Various Block Co-ordination Properties

The various Block Coordination Properties are

a) Immediate

            Default Setting. The Detail records are shown when the Master Record are shown.

b) Deffered with Auto Query

Oracle Forms defer fetching the detail records until the operator navigates to the detail block.

c) Deferred with No Auto Query

The operator must navigate to the detail block and explicitly execute a query

 How to attach same LOV to multiple items

We can use the same LOV for 2 columns by passing the return values in global values and using the global values in the code.

Object Groups (Use)

An object group is a container for a group of objects. You define an object group when you want to package related objects so you can copy or subclass them in another module.

Object groups provide a way to bundle objects into higher-level building blocks that can be used in other parts of an application and in subsequent development projects. For example, you might build an appointment scheduler in a form and then decide to make it available from other forms in your applications. The scheduler would probably be built from several types of objects, including a window and canvas, blocks, and items that display dates and appointments, and triggers that contain the logic for scheduling and other functionality. If you packaged these objects into an object group, you could then copy them to any number of other forms in one simple operation.

You can create object groups in form and menu modules. Once you create an object group, you can add and remove objects to it as desired.

Types of Canvases (Stacked/Content Difference)

(i)                 Content Canvas (Default Canvas) [A content canvas is the required on each window you create]

(ii)               Stack Canvas  [you can display more then one stack canvas in a window at the same time]  

(iii)             Tab Type Window [In Tab canvas that have tab pages and have one or more then tab page] 

(iv)             Toolbar Canvas [A toolbar canvas often is used to create Toolbar Windows. There are two type of Toolbar window.

a.       Horizontal Toolbar Canvas: - Horizontal Toolbar canvases are displayed at the top of the window, Just Under the Main Menu Bar.

b.      Vertical Toolbar Canvas: - While vertical Toolbar are displayed along the Left Edge of the window.

Call From/New Form/Open Form (Difference)

Call Form: Runs an indicated form while keeping the parent form active.  Form Builder runs the called form with the same Runform preferences as the parent form.  When the called form is exited Form Builder processing resumes in the calling form at the point from which you initiated the call to CALL_FORM.

PROCEDURE CALL_FORM (formmodule_name VARCHAR2, display NUMBER, switch_menu NUMBER, query_mode NUMBER, data_mode NUMBER, paramlist_name/id VARCHAR2);

New Form: Exits the current form and enters the indicated form.  The calling form is terminated as the parent form.  If the calling form had been called by a higher form, Form Builder keeps the higher call active and treats it as a call to the new form.  Form Builder releases memory (such as database cursors) that the terminated form was using.

Form Builder runs the new form with the same Runform options as the parent form.  If the parent form was a called form, Form Builder runs the new form with the same options as the parent form.

PROCEDURE NEW_FORM (formmodule_name VARCHAR2, rollback_mode NUMBER, query_mode NUMBER, data_mode NUMBER, paramlist_name/id VARCHAR2);

Open Form: Opens the indicated form.  Use OPEN_FORM to create multiple-form applications, that is, applications that open more than one form at the same time.

PROCEDURE OPEN_FORM (form_name VARCHAR2, activate_mode NUMBER, session_mode NUMBER, data_mode NUMBER, paramlist_id/name PARAMLIST);

Key-next/Post-Text (Difference)

Post-Text–Item: Fires during the Leave the Item process for a text item.  Specifically, this trigger fires when the input focus moves from a text item to any other item.

Key-Next-Item: The key-next is fired as a result of the key action. Key next will not fire unless there is a key event.

Object Libraries (Use/Benefits)

The Object Library provides an easy method of reusing objects and enforcing standards across the entire development organization.

Object Library can be used to:

1.      Create, store, maintain, and distribute standard and reusable objects. 

2.      Rapidly create applications by dragging and dropping predefined objects to your form.

            There are several advantages to using object libraries to develop applications:

1.      Object libraries are automatically re-opened when you startup Form Builder, making your reusable objects immediately accessible.

2.      You can associate multiple object libraries with an application.  For example, you can create an object library specifically for corporate standards, and you can create an object library to satisfy project-specific requirements.

3.      Object libraries feature Smart Classes-- objects that you define as being the standard.  You use Smart Classes to convert objects to standard objects.

Dynamically create LOV/List Item

You can also add list elements individually at runtime by using the ADD_LIST_ELEMENT built-in subprogram, or you can populate the list from a record group at runtime using the POPULATE_LIST built-in. If you populate the list from a record group, be sure that the record group you are using to populate the list contains the relevant values before you call POPULATE_LIST. If the record group is a static record group, it will already contain the appropriate values. Otherwise, you should populate the group at runtime using one of the record group subprograms.

Master-Detail Relation (Triggers/Procedures/Properties)

On-Check-Delete-Master: - Fires when Form Builder attempts to delete a record

in a block that is a master block in a master-detail relation.
On-Clear-Details: - Fires when Form Builder needs to clear records in a block that is a detail block in a master-detail relation because those records no longer correspond to the current record in the master block.
On-Populate-Details: - Fires when Form Builder needs to fetch records into a block that is the detail block in a master-detail relation so that detail records are synchronized with the current record in the master block.

(i)         Isolated: - Masters Can be deleted when Child is existing

Triggers: - On Populate details             Block

                  On Clear Details                 Form 

Procedure

                        Check Package Failure

                        Clear all master Detail

                        Query Master Detail              

(ii)        Non- Isolated: - Masters Cannot be deleted when Child is existing.

Triggers: - On Populate details            Block

                  On Check Delete master    Block            

                              On Clear Details               Form  

Procedure

                        Check Package Failure

                        Clear all master Detail

                        Query Master Detail              

(iii)       Cascading: - Child Record Automatically Deleted when Masters is deleted.

Triggers: - On Populate details             Block

                  Pre Delete                                       Block

   On Clear Details                 Form 

Procedure

                        Check Package Failure

                        Clear all master Detail

                        Query Master Detail               

Sequence of Trigger Fire while Committing

  KEY Commit

  Pre Commit

  Pre/On/Post Delete

 Pre/On/Post Update

  Pre/On/Post Insert

 On commit

  Post Database Commit

Types of Triggers in Forms

• Block-processing triggers: - Block processing triggers fire in response to events related to record management in a block. E.g. When-Create-Record, When-Clear-Block, When-Database-Record, When-Remove-Record

• Interface event triggers: - Interface event triggers fire in response to events that occur in the form interface.  Some of these triggers, such as When-Button-Pressed, fire only in response to operator input or manipulation.  Others, like When-Window-Activated, can fire in response to both operator input and programmatic control. E.g. When-Button-Pressed, When-Checkbox-Changed, Key- [all], When-Radio-Changed, When-Timer-Expired, When-Window-Activated, When-Window-Resized

• Master-detail triggers: - Form Builder generates master-detail triggers automatically when you define a master-detail relation between blocks.  The default master-detail triggers enforce coordination between records in a detail block and the master record in a master block.  Unless you are developing your own custom block-coordination scheme, you do not need to define these triggers yourself.  Instead, simply create a relation object, and let Form Builder generate the triggers required to manage coordination between the master and detail blocks in the relation. E.g. On-Check-Delete-Master, On-Clear-Details, On-Populate-Details

• Message-handling triggers: - Form Builder automatically issues appropriate error and informational messages in response to runtime events.  Message handling triggers fire in response to these default messaging events. E.g. On-Error, On-Message

• Navigational triggers: - Navigational triggers fire in response to navigational events.  For instance, when the operator clicks on a text item in another block, navigational events occur as Form Builder moves the input focus from the current item to the target item.  Navigational events occur at different levels of the Form Builder object hierarchy (Form, Block, Record, Item).  Navigational triggers can be further sub-divided into two categories:  Pre- and Post- triggers, and When-New-Instance triggers. Pre- and Post- triggers fire as Form Builder navigates internally through different levels of the object hierarchy.  As you might expect, these triggers fire in response to navigation initiated by an operator, such as pressing the [Next Item] key.  However, be aware that these triggers also fire in response to internal navigation that Form Builder performs during default processing.  To avoid unexpected results, you must consider such internal navigation when you use these triggers. E.g. Pre-Form, Pre-Block, Pre-Text-Item, Post-Text-Item, Post-Record, Post-Block, Post-Form

When-New-Instance triggers fire at the end of a navigational sequence that places the input focus in a different item.  Specifically, these triggers fire just after Form Builder moves the input focus to a different item, when the form returns to a quiet state to wait for operator input. Unlike the Pre- and Post- navigational triggers, the When-New-Instance triggers do not fire in response to internal navigational events that occur during default form processing.  E.g. When-New-Form-Instance, When-New-Block-Instance, When-New-Record-Instance, When-New-Item-Instance

• Query-time triggers: - Query-time triggers fire just before and just after the operator or the application executes a query in a block. E.g. Pre-Query, Post-Query

• Transactional triggers: - Transactional triggers fire in response to a wide variety of events that occur as a form interacts with the data source. E.g. On-Delete, On-Insert, On-Lock, On-Logon, On-Update, Post-Database-Commit, Post-Delete, Post-Forms-Commit, Post-Insert, Post-Update, Pre-Commit, Pre-Delete, Pre-Insert, Pre-Update

• Validation triggers: - Validation triggers fire when Form Builder validates data in an item or record.  Form Builder performs validation checks during navigation that occurs in response to operator input, programmatic control, or default processing, such as a Commit operation. E.g. When-Validate-Item, When-Validate-Record