, ,

Triggers in Oracle Forms

Triggers are blocks of PL/SQL code that are written to perform tasks when a specific event occurs within an application. In effect, an Oracle Forms trigger is an event-handler written in PL/SQL to augment (or occasionally replace) the default processing behavior. Every trigger has a name, and contains one or more PL/SQL statements. A trigger encapsulates PL/SQL code so that it can be associated with an event and executed and maintained as a distinct object.

Block Processing Triggers:

Block processing triggers fire in response to events related to record management in a block.
  • When-Create-Record Perform an action whenever Oracle Forms attempts to create a new record in a block.
  • When-Clear-Block Perform an action whenever Oracle Forms flushes the current block; that is, removes all records from the block.
  • When-Database-Record Perform an action whenever Oracle Forms changes a record’s status to Insert or Update, thus indicating that the record should be processed by the next COMMIT_FORM operation.

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.
  • When-Button-Pressed Initiate an action when an operator selects a button, either with the mouse or through keyboard selection.
  • When-Checkbox-Changed Initiate an action when the operator toggles the state of a check box, either with the mouse or through keyboard selection.
  • When-Image-Activated Initiate an action whenever the operator double-clicks an image item.
  • When-Image-Pressed Initiate an action whenever an operator clicks on an image item.
  • When-Radio-Changed Initiate an action when an operator changes the current radio button selected in a radio group item.
  • When-Window-Activated Initiate an action whenever an operator or the application activates a window.
  • When-Window-Closed Initiate an action whenever an operator closes a window with the window manager’s Close command.
  • When-Window-Deactivated Initiate an action whenever a window is deactivated as a result of another window becoming the active window.

Master/Detail Triggers:

Oracle Forms generates master/detail triggers automatically when a master/detail relation is defined between blocks. The default master/detail triggers enforce coordination between records in a detail block and the master record in a master block. Unless developing custom block-coordination schemes, you do not need to define these triggers.
  • On-Check-Delete-Master Fires when Oracle Forms attempts to delete a record in a block that is a master block in a master/detail relation.
  • On-Clear-Details Fires when Oracle Forms 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 Oracle Forms 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.

Message-Handling Triggers:

Oracle Forms automatically issues appropriate error and informational messages in response to runtime events. Message handling triggers fire in response to these default messaging events.
  • On-Error Replace a default error message with a custom error message, or to trap and recover from an error.
  • On-Message To trap and respond to a message; for example, to replace a default message issued by Oracle Forms with a custom message.

Validation Triggers:

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

Navigational Triggers:

Navigational triggers fire in response to navigational events. 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 Oracle Forms navigates internally through different levels of the object hierarchy. When-New-Instance-Triggers fire at the end of a navigational sequence that places the input focus on a different item.
  • Pre-Form Perform an action just before Oracle Forms navigates to the form from “outside” the form, such as at form startup.
  • Pre-Block Perform an action before Oracle Forms navigates to the block level from the form level.
  • Pre-Record Perform an action before Oracle Forms navigates to the record level from the block level.
  • Pre-Text-Item Perform an action before Oracle Forms navigates to a text item from the record level.
  • Post-Text-Item Manipulate an item when Oracle Forms leaves a text item and navigates to the record level.
  • Post-Record Manipulate a record when Oracle Forms leaves a record and navigates to the block level.
  • Post-Block Manipulate the current record when Oracle Forms leaves a block and navigates to the form level.
  • Post-Form Perform an action before Oracle Forms navigates to “outside” the form, such as when exiting the form.
  • When-New-Form-Instance Perform an action at form start-up. (Occurs after the Pre-Form trigger fires).
  • When-New-Block-Instance Perform an action immediately after the input focus moves to an item in a block other than the block that previously had input focus.
  • When-New-Record-Instance Perform an action immediately after the input focus moves to an item in a different record.
  • When-New-Item-Instance Perform an action immediately after the input focus moves to a different item. 

Transactional Triggers:

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

Query-Time Triggers:

Query-time triggers fire just before and just after the operator or the application executes a query in a block.
  • Pre-Query Validate the current query criteria or provide additional query criteria programmatically, just before sending the SELECT statement to the database.
  • Post-Query Perform an action after fetching a record, such as looking up values in other tables based on a value in the current record. Fires once for each record fetched into the block.
/by
,

Modal & Modeless Windows in Oracle Forms

A window in oracle forms is a container for all visual objects that make up a Forms application. You can create two different type of windows in oracle forms. Lets have a brief comparisons between these two types of windows.
Modal Window:
A modal window is a restricted window that the user must respond to before moving the input focus to another window. Modal windows:
  • Must be dismissed before control can be returned to a modeless window
  • Become active as soon as they display
  • Require a means of exit or dismissal
Modeless Window:
A modeless window is an unrestricted window that the user can exit freely. Modeless windows:
  • Can display many at once
  • Are not necessarily active when displayed
  • Are the default window type
/by
,

Various Canvas Types in Oracle Forms

What is a Canvas?
A canvas is a surface inside a window container on which you place visual objects such as interface items and graphics. It is similar to the canvas upon which a picture is painted. To see a canvas and its contents at run time, you must display it in a window. A canvas always displays in the window to which it is assigned.
Canvas Types
Oracle Forms provides four types of canvases, all of which can be displayed in the same window at runtime. A canvas’ type defines how Oracle Forms will display it in the window to which it is assigned. When you create a canvas, you specify its type by setting the Canvas Type property.
The four canvas types are:
  • Content
  • Stacked
  • Tab
  • Toolbar
Content Canvas:
The most common canvas type is the content canvas (the default type). A content canvas is the “base” view that occupies the entire content pane of the window in which it is displayed. You must define at least one content canvas for each window you create.
When building an application, one of the first steps is to create content canvases that will be displayed in the windows of your form(s). While you can assign more than one content canvas to the same window at design time, at runtime only one content canvas is displayed at one time in the window.
Stacked Canvas:
A stacked canvas is displayed at top—or stacked on—the content canvas assigned to the current window. Stacked canvases obscure some part of the underlying content canvas, and often are shown and hidden programmatically. You can display more than one stacked canvas in a window at the same time.
Stacked canvases are displayed in a window along with the window’s content canvas(es) and any number of other stacked canvases. You can set the bevel, color, and pattern attributes of a stacked canvas to make it look different than the underlying content canvas.
Creating a stacked canvas is similar to creating a content canvas. To define a stacked canvas, you need to set certain canvas properties that apply only to stacked canvases, and create items and boilerplate text and graphics as you would for a content canvas. To convert an existing content canvas to a stacked canvas, simply change its Canvas Type property from Content to Stacked.
Tab Canvas:
A tab canvas—made up of one or more tab pages—allows you to group and display a large amount of related information on a single dynamic Oracle Forms canvas object. Like stacked canvases, tab canvases are displayed on top of a content canvas, partly obscuring it. Tab pages (that collectively comprise the tab canvas) each display a subset of the information displayed on the entire tab canvas.
A tab canvas can have many tab pages, and must have at least one. Think of tab pages as the folders in a filing system. Each individual tab page (folder) has a labelled tab that developers and end users click to access the page. At design time or runtime, you click the labelled tab to display the page at the front of the tab canvas, thereby obscuring any other page(s).
Tab pages are sub-objects of a tab canvas. Like the canvas to which it is attached, each tab page has properties; similarly, any item you place on a tab canvas has a canvas property as well as tab page properties. The ordering of tab pages in the Object Navigator determines the left-to-right (or top-to-bottom) order of the tabs at runtime.
Toolbar Canvas:
A toolbar canvas often is used to create toolbars for individual windows. You can create two types of toolbar canvases: horizontal or vertical. Horizontal toolbar canvases are displayed at the top of a window, just under its menu bar, while vertical toolbars are displayed along the far left edge of a window.
You can create toolbar canvases, both horizontal and vertical, for any window in a form. Oracle Forms displays horizontal toolbar canvases across the top of a window, and vertical toolbar canvases on the left edge of a window.
When you create a toolbar canvas, you assign it to a window by setting the canvas Window property, and then register it with the window by setting the window’s Vertical Toolbar Canvas or Horizontal Toolbar Canvas properties as appropriate. You can change the appearance of a toolbar at runtime by dynamically showing and hiding different items on the toolbar. You also can create more than one toolbar for the same window, and display them in response to navigation events and programmatic control, much like stacked canvases assigned to the same window.
/by
, ,

Fundamentals of object sharing in Oracle Forms 10g

This article is all about the fundamentals of sharing the objects in Oracle Forms , its benefits and the various ways to do it. It will describes the various methods for reusing objects – Property Classes, Copying and Subclassing Objects and Code, Object Groups, Object Libraries and  SmartClasses.
When you share and reuse objects and code, you increase productivity, decrease maintenance, increase modularity, and improve the performance of your applications. When you are developing applications, you should share and reuse objects and code wherever possible.
There are many advantages of sharing and reusing objects and code.
  • You can develop applications much more effectively and efficiently if you are not trying to “start over” each time you write a piece of code. By sharing and reusing frequently used objects and code, you can cut down development time and increase productivity.
  • You can decrease maintenance time by creating applications that use or call the same object or piece of code several times.
  • You can maintain standards by reusing objects and code.
To maximize reuse, the developer should apply the following guidelines in the order shown:
  • Accept default properties as much as possible
  • Use SmartClasses to describe an object
  • Use sets of visual attributes
 Now lets discuss the various methods of object sharing:
A) Property Class 
A property class is a named object that contains a list of properties and their settings. You can use property classes to increase productivity and improve network performance.

 Here are some of the uses of a property class:
  • It increases productivity by setting standard or frequently used values for common properties and associates them with several form builder objects.
  • It defines standard properties not just for one particular object but also for several at a time. This results in increased productivity, because it eliminates the time spent on setting identical properties for several objects.
  • It improves network performance by increasing the efficiency of message diffing.
 Note: Once an item is defined, the meta-data about the next item includes only those properties that differ from the previous item. This is referred to as message diffing.
Creating a Property Class
When you create a property class, you have all the properties from every Forms Builder object available. You choose the properties and their values to include in the property class. You can create a property class in two ways:
  • Using the Create button in the Object Navigator
  • Using the Create Property Class button
Steps to create a property class from the Object Navigator:
  1. Select the Property Class node.
  2. Select Create.
  3. Add the required properties and their values.
  4. Set the value for that property.
Steps to create a property class from the Property Palette
  1. Select the object in the Object Navigator.
  2. Select the properties to be copied into a property class in the Property Palette.
  3. Select the Property Class button.
  4. Locate the property class and change its name in the Object Navigator.
Inheriting from a Property Class
Once you create a property class and add properties, you can use the property class. To apply the properties from a property class to an object, use the Subclass Information property in the Property Palette.
What is an inherited property?
An inherited property is one that takes its value from the property class that you associated with the object. An inherited property is displayed with an arrow to the left of the property name.
What is a variant property?
A variant property is one that has a modified value even though it is inherited from the property class associated with the object. You can override the setting of any inherited property to make that property variant. Variant properties are displayed with a red cross over an arrow.
Notes:
  • To convert an inherited property to a variant property, simply enter a new value over the inherited one.
  • To convert a variant property to an inherited property, click the Inherit icon in the Property Palette.
  • You can also use the Inherit icon to revert a changed property back to its default.
B) Copying and Subclassing Objects and Code
With subclassing you can make an exact copy, and then alter the properties of some objects if desired. If you change the parent class, the changes also apply to the properties of the subclassed object that you have not altered. However, any properties that you override remain overridden. This provides a powerful object inheritance model.
When you subclass a data block, you can:
  • Change the structure of the parent, automatically propagating the changes to the child
  • Add or change properties to the child to override the inheritance
You can copy or subclass objects:
  • Between modules, by dragging objects between the modules in the Object Navigator
  • Within a single module by selecting the object in the Object Navigator, pressing [Ctrl], and dragging it to create the new object
When you drag objects, a dialog box appears that asks whether you want to copy or subclass the object.
Copy or Subclass?
When you copy an object, a separate, unique version of that object is created in the target module. Any objects owned by the copied object also get copied. Changes made to a copied object in the source module do not affect the copied object in the target module.
With subclassing, you can make an exact copy, and then alter the properties of some objects. If you change the parent class, the changes also apply to the properties of the subclassed object that you have not altered.
When you subclass a data block you cannot:
  • Delete items from the child
  • Change the order of items in the child
  • Add items to the child unless you add them to the end
C) Object Groups
An object group is a logical container for a set of Forms Builder objects.
You need to define an object group when you want to package related objects for copying or subclassing in another module or if you want to bundle numerous objects into higher-level building blocks that you can use again in another application. You can package the various objects in an object group and copy the entire bundle in one operation.
Steps to create an object group
  1. Select the Object Group node in the Object Navigator.
  2. Select the Create icon.
  3. Rename the new object group that is displayed.
  4. Click the form module and expand all the nodes.
  5. Select all the objects of one type that you want to include in the object group.
  6. Drag the selected objects into the new object group entry.
Key notes about object groups
  • Including a block in an object group also includes its items, the item-level triggers, the block-level triggers and the relations. You cannot use any of these objects in an object group without the block.
  • It is not possible to include another object group.
  • Deleting an object from a module automatically deletes the object from the object group.
  • Deleting an object group from a module does not delete the objects it contains from the module.
D) Object Libraries
Object libraries are convenient containers of objects for reuse. They simplify reuse in complex environments, and they support corporate, project, and personal standards. An object library can contain simple objects, property classes, object groups, and program units, but they are protected against change in the library. Objects can be used as standards (classes) for other objects.
Why object libraries instead of object groups?
  • Object libraries are external to the form, so are easily shared among form modules.
  • Object libraries can contain individual items; for example, iconic buttons. The smallest unit accepted in an object group is a block.
  • Object libraries accept PL/SQL program units.
  • If you change an object in an object library, all forms that contain the subclassed object reflect the change.
Object libraries appear in the Navigator if they are open. You can create, open, and close object libraries like other modules. Forms Builder automatically opens all object libraries that were open when you last closed Forms Builder.
Note: You cannot modify objects inside the object library itself. To make changes, drag the object into a form, change it, and drag it back to the object library.
Steps to populate an Object Library
  1. Select Tools > Object Library to display the object library.
  2. Drag objects from the Object Navigator into the object library.
  3. You can edit the descriptive comment by clicking the Edit icon in the object library interface.
E) SmartClass
A SmartClass is a special member of an Object Library. It can be used to easily subclass existing objects in a form using the SmartClass option from the right mouse button popup menu.
To use Object Library members which are not SmartClasses, you have to use the Subclass Information dialog available in the Property Palette of the form object that you are modifying.
If you frequently use certain objects as standards, such as standard buttons, date items, and alerts, you can mark them as SmartClasses by selecting each object in the object library and choosing Edit > SmartClass. You can mark many different objects, spread across multiple object libraries, as SmartClasses.
To apply a SmartClass to a Forms object, perform the following steps:
1. Right-click an object in the Layout Editor or Navigator.
2. From the pop-up menu, select SmartClasses. The SmartClasses pop-up menu lists all the SmartClasses from all open object libraries that have the same type as the object, and, for items, also have the same item type; for example, push button, text item.
3. Select a class for the object; it then becomes the parent class of the object. You can see its details in the Subclass Information dialog box in the object’s Property Palette, just like any other subclassed object.
/by
,

The Runtime Process of a Oracle Forms

In this article we will discuss how a Oracle Form runs in a server and how the client machines access them.
Oracle Forms applications are deployed to the web through a three-tier architecture. Application logic and the Forms Services Runtime Engine reside on the middle-tier application server. All trigger processing occurs on database and application servers, while user interface processing occurs on the Forms client. End users can run Forms Developer applications in a Web browser.
Before discussing the runtime process, lets go through the Forms Services Architecture in brief. Forms Services consists of four major components: the Forms Servlet, the Java client (Forms Client), the Forms Listener Servlet, and the Forms Runtime Engine.

Forms Services Architecture
The Forms Servlet is a Java servlet(class) that is capable of creating a dynamic HTML file in the client browser.
The Java client or Forms client(applet) is nothing but a set of Java classes that are downloaded to the client machine when any Form application is called in the client machine for the first time. This component is only responsible to display the Form in the Browser and send the user interactions to the middle tier. You do not have to deploy a separate Java applet for each application. The same generic applet is used to run any Forms Services application, regardless of its size and complexity.

The Forms Listener Servlet is a Java servlet that runs in a Web server equipped with a servlet engine, such as OC4J. The Forms Listener Servlet is in charge of managing the creation of the Forms Runtime process for each client and managing the network communications that occur between the client and its associated Forms Runtime process, through the Web server.
The Forms Runtime Engine is a process on the Application Server that is started by the Forms Listener Servlet. The Forms Runtime Engine handles all the application logic and Forms functionality and executes the code written into the application.
Users request a Form application in their Web browsers by entering a URL that points to the application. Forms Services then generates an HTML file that downloads a Java applet to the client machine. This small applet is capable of displaying the user interface of any form, while the application logic is executed on the middle tier.
The URL to invoke an application must have the following format:
http://host[:port]/forms servlet or html file[parameters] (optional portions of URL enclosed in brackets)
For Example:http://dummysite.com:8888/forms90/f90servlet
Where http is a protocol, dummysite.com is the host, 8888 is the port number and forms90/f90servlet is forms servlet alias.
We should have a Java Runtime Environment(JRE) in the client machine to run our Forms. We can use JInitiator, a plug-in that provides a JRE capable of running the Forms applet.
The below is the complete process how we can access a Form application through web:

Oracle Forms Runtime
1] The user accesses the Forms application through a URL in the web browser.
http://dummysite.com:8888/forms90/f90servlet
2] In the middle tier, Oracle HTTP Server or OC4J receives an HTTP request from the browser client and contacts the Forms Servlet.
3] The Forms Servlet dynamically creates an HTML page in the client machine containing all the information to start the Forms session.

Oracle Forms Runtime
4] The Oracle HTTP Server or OC4J downloads a generic applet to the client machine if the Form is called for the first time. The client machine caches the applet so that it can run future Forms applications without downloading it again.
5] The applet in the client machine contacts the Forms Listener Servlet in the middle tier to start the session. The Forms Listener Servlet starts an instance of the Forms Runtime Engine on the Forms Server (middle tier).
6] The Forms Listener Servlet establishes a connection with the Runtime Engine, which connects to the database if needed and loads application executable files.

Oracle Forms Runtime
7] The Forms applet displays the Form in the main window of the user’s Web browser.
8] The Forms Listener Servlet, working through OC4J or the HTTP Server, manages communication between the Forms applet and the Runtime Engine.
/by