1. Working with Oracle Forms
  2. Integration
  3. Working with Server and System Events
  4. Event Propagation

Event Propagation

In a situation where a Forms client is idle, since Oracle Forms is driven by the HTTP protocol, which is a request/response protocol only, nothing can change on the client if the client is idle.

An applet parameter MaxEventWait, expressed in milliseconds, governs how long the application should wait before checking for an event. In other words, you can specify how often the client should send a request to the server, thus causing the execution of the PL/SQL that is specified as a response to an event.

Note, however, that, on the server-side, Forms Services receives all the events without polling. However, the server does not start running the WHEN_EVENT_RAISED triggers until it receives the notification from the Forms Client (because of the HTTP request/reply paradigm of the Forms Client and hence the need for the MaxEventWait property).

Figure -25 Notification flow with idle or active clients

Description of Figure -25 follows
Description of "Figure -25 Notification flow with idle or active clients"

When-Event-Raised Trigger

Oracle Forms responds to or fires a trigger in response to a variety of events. For both Forms Developer and internal events, Forms provides entry points in terms of triggers so that an application developer can associate and execute some code in response to an event.

For example, a defined trigger is attached to a specific object in a form. The object to which a trigger is attached defines the scope of the trigger. For example, the WHEN-BUTTON-PRESSED trigger corresponds to the Button Pressed event which occurs when an operator selects a button. The name of the trigger establishes the association between the event and the trigger code. When a user clicks on a button, Forms responds by executing the code in the WHEN-BUTTON-PRESSED trigger.

This new event object has a corresponding trigger defined at the event object level. The WHEN-EVENT-RAISED trigger fires in response to the occurrence of a database event for which it has a subscription. The firing of the new trigger is similar to the internal processing of triggers. However, the source of the event is, in this case, an external event such as a database event (firing because of an operation) and not the result of any user interaction with forms or because of an internal form processing.

Trigger Definition Level and Scope

Oracle Forms triggers are usually attached to a specific object, such as an item, block, or Form. The object to which a trigger is attached determines the trigger's definition level in the object hierarchy. A trigger's definition level determines the trigger's scope. The scope of a trigger is its domain within the Forms object hierarchy, and determines where an event must occur for the trigger to respond to it. Although the WHEN-EVENT-RAISED trigger is attached to an event object, it has an application level scope because of the nature of the server-centric events. When the event notification is invoked because of an asynchronous callback mechanism for registered database events, any number of forms running within that application and with a subscription for that event receive the notification. This alleviates the need for the application developer to code complex logic to deal with the event.

There is also a Form-level scope so that the event will only be handled if the application is running the specific form from where the event is defined.