Intelligence with Regard to Form Object Properties

This section presents examples of how Forms uses object properties to exhibit smart rules. It also presents examples that show how Forms fails to be smart while using certain object properties.

How Forms Ignores Object Property Values and Thereby Enforces Smart Rules

Forms ignores object property values and thereby enforces smart rules. I will illustrate this with an example. The block property Single Record is ignored when set to Yes for a data block.

The block property Insert Allowed doesn't prevent the record(s) in the block from being de- marked for insertion. It only prevents you from entering a new record after it was turned off. Forms is intelligent enough to prevent the record(s) from being marked for an INSERT, UPDATE, or DELETE operation only from the point when the Insert Allowed, Update Allowed, or Delete Allowed properties are turned off, respectively. This means records already marked for DML before turning off the corresponding property maintain their status dynamically.

I will illustrate this with an example. Consider a data block with the Enforce Primary Key property set to TRUE. At design time, the Insert Allowed property for the block was True. In an appropriate trigger, before committing, based on runtime conditions, I dynamically set the Insert Allowed property for the same block as follows :

IF  THEN

SET_BLOCK_PROPERTY('', INSERT_ALLOWED, PROPERTY_FALSE);

END IF;

Note that I might have entered new records in the block before this code is executed. I also have a simple KEY-COMMIT trigger as follows:

KEY-COMMIT



IF FORM_SUCCESS THEN

 COMMIT_FORM;

END IF;

The uniqueness of the record is still checked and Forms raises the error:

FRM-40600: Record has already been inserted.

when it encounters a duplicate record. This shows that the record marked for insertion in the form before the resetting of the Insert Allowed property retains its INSERT status, and Enforce Primary key applies to those records that have INSERT status at the time of commit. Turning off the Insert Allowed property prevents subsequent entry of new records.

Finally, note that the item property Tooltip_Text, when dynamically set to null for an item, prevents the tool tip from being displayed when the mouse is on the item.

How Forms Fails to Be Smart While Using Some Object Property Values

Contrary to the ideas contained in the preceding section, Forms 5.0 isn't always smart enough to ignore object property values to enforce smart rules. The following subsections present examples that support this statement.

How Smart Is Forms in Implementing Query-Only Mode?

Calling Forms in query-only mode is as simple as specifying the constant QUERY_ONLY to CALL_FORM or NEW_FORM. Have you ever thought of how to check whether a form is running in query-only mode? There seems to be no direct way except to use a parameter or global variable. An intelligent Forms should give the capability of a form-level property, say QUERY_ONLY, for this purpose. But unfortunately , such a thing does not exist.

Now what about the properties Insert Allowed, Update Allowed, and Delete Allowed for each of the data blocks in the form? Does Forms turn them off automatically when running the form in query-only mode and reset them to their previously set values at other times?

The answer is an alarming "no." This shows that

• These object-level properties have nothing to do with the running functionality of the form, which is query-only. Though these properties are meant to toggle the operations of INSERT, UPDATE, and DELETE and though Forms prevents these operations in query-only mode, Forms doesn't keep their values in sync with the running condition. This might seem to be vague because there is no need to do so as long as it prevents DML, but my point here is: The right properties should have the right values at the right times.
• These object-level properties aren't really 100% dynamic (keeping in view the previous point), and SET_BLOCK_PROPERTY sets them dynamically only to a certain degree. At other times, they pertain only to the values set in the designer.

Another example to substantiate these two statements is the form level Validation property. Does it turn off the default validation when running in query-only mode? No. The value of the property is still TRUE.

Other Non-smart Object Properties

The block property Enforce Primary key, when set to TRUE for a data block, is taken into account when an ON-INSERT trigger is written for that block. My point of argument is that the purpose of an ON-INSERT trigger is to replace the default insertion into the base table. So most likely, its trigger text doesn't have an INSERT into the base table. If it does have an UPDATE of the base table, I still feel comfortable that Oracle doesn't allow an update of the primary key columns . Any other INSERT, UPDATE, or DELETE statements can be easily done with PRE- and POST- INSERT, UPDATE, and DELETE triggers.

Forms is not smart enough to check the text of the ON-INSERT trigger to check for this point so that it can ignore a check for the FRM-40600 error. This can be taken care of at compile time for the ON-INSERT trigger. What an intelligent compile time error this would be. Indeed it's not just intelligence, but complex or high intelligence to check for an insert statement in the trigger body, especially if such a statement is embedded in a program unit, either in Forms or in the database.

Let's refer again to the item property Tooltip_Text. Setting it to null dynamically prevents the tool tip from being displayed, but if you reset it to a non-null value, the tool tip still doesn't appear.

There are lots of Forms object properties that are smart enough in one way but not in other ways. The preceding two sections illustrated just some of them.