Saturday, June 30, 2012

Window Block



Previous | Page 1 of 2 | Next

Windows and Blocks

Form Builder processes many events based on blocks (and items), which can be completely independent of windows (and canvases). Keep in mind the following characteristics of windows and blocks.

Connection Between Windows and Blocks

* A window can contain multiple canvases, and multiple items can be located on a canvas.
* A block can contain multiple items, and an item is located on one and only one canvas (except for null canvas items).
* A window can contain multiple blocks, and a block can be located on several windows.
Note: In general, put blocks in separate windows. If blocks are closely related (through a foreign-key relationship), put them in the same window.

Window Activation and Block Navigation

You can use the When-Window-Activated trigger to activate another window automatically (see the Closing Windows example later in this module).

Transaction Management

During commit processing, Forms processes all base blocks in sequential order. Therefore, transaction management is block-based rather than window-based. However the user expects to interact with a form in a window-based manner.

Manipulating Windows

Using Window-Interaction Triggers

You can use four window-interaction triggers to provide extra functionality whenever a user interacts with a window. These triggers should be defined at the form level.

Using Window-Interaction Triggers

The common uses for these triggers are as follows:
Trigger Use
When-Window-Activated Captures initial settings of window properties; enforces navigation to a particular item whenever the window is activated.
When-Window-Deactivated Deactivates a window.
When-Window-Closed Closes a window programmatically.
When-Window-Resized Maintains visual standards; captures window properties.

Keeping Track of the Triggered Window

The SYSTEM.EVENT_WINDOW system variable contains the name of the last window for which a window-interaction trigger fired. You can use this system variable to perform different actions for different windows in your window-interaction triggers.



Trigger Characteristic
When-Window-Activated Fires when a window is made the active window. (Note that window activation can occur independently of navigation).
When-Window-Deactivated Fires when a user deactivates a window by setting the input focus to another window.
When-Window-Closed Fires when a user closes a window by using a window-manager-specific Close command.
When-Window-Resized Fires when a window is resized, either by the user or through a trigger. (It also fires at form startup, but not when a window is made into an icon).

Do_key

DO_KEY Built-in

Description

Executes the key trigger that corresponds to the specified built-in subprogram. If no such key trigger exists, then the specified subprogram executes. This behavior is analogous to pressing the corresponding function key.

Syntax

PROCEDURE DO_KEY
(built_in_subprogram_name VARCHAR2);
Built-in Type restricted procedure
Enter Query Mode yes

Parameters

built_in_subprogram_name 
 
Specifies the name of a valid built-in subprogram.
Built-in
Key Trigger
Associated Function Key
CLEAR_BLOCK
Key-CLRBLK
[Clear Block]
CLEAR_FORM
Key-CLRFRM
[Clear Form]
CLEAR_RECORD
Key-CLRREC
[Clear Record]
COMMIT_FORM
Key-COMMIT
[Commit]
COUNT_QUERY
Key-CQUERY
[Count Query Hits]
CREATE_RECORD
Key-CREREC
[Insert Record]
DELETE_RECORD
Key-DELREC
[Delete Record]
DOWN
Key-DOWN
[Down]
DUPLICATE_ITEM
Key-DUP-ITEM
[Duplicate Item]
DUPLICATE_RECORD
Key-DUPREC
[Duplicate Record]
EDIT_TEXTITEM
Key-EDIT
[Edit]
ENTER
Key-ENTER
[Enter]
ENTER_QUERY
Key-ENTQRY
[Enter Query]
EXECUTE_QUERY
Key-EXEQRY
[Execute Query]
EXIT_FORM
Key-EXIT
[Exit/Cancel]
HELP
Key-HELP
[Help]
LIST_VALUES
Key-LISTVAL
[List]
LOCK_RECORD
Key-UPDREC
[Lock Record]
NEXT_BLOCK
Key-NXTBLK
[Next Block]
NEXT_ITEM
Key-NEXT-ITEM
[Next Item]
NEXT_KEY
Key-NXTKEY
[Next Primary Key Fld]
NEXT_RECORD
Key-NXTREC
[Next Record]
NEXT_SET
Key-NXTSET
[Next Set of Records]
PREVIOUS_BLOCK
Key-PRVBLK
[Previous Block]
PREVIOUS_ITEM
Key-PREV-ITEM
[Previous Item]
PREVIOUS_RECORD
Key-PRVREC
[Previous Record]
PRINT
Key-PRINT
[Print]
SCROLL_DOWN
Key-SCRDOWN
[Scroll Down]
SCROLL_UP
Key-SCRUP
[Scroll Up]
UP
Key-UP
[Up]

DO_KEY Restrictions

  • DO_KEY accepts built-in names only, not key names: DO_KEY(ENTER_QUERY).

    To accept a specific key name, use the EXECUTE_TRIGGER built-in: EXECUTE_TRIGGER('KEY_F11').

DO_KEY Example

/*
   
** Built-in: DO_KEY 
** Example: Simulate pressing the [Execute Query] key. 
*/ 
BEGIN 
   DO_KEY('Execute_Query'); 
END; 

FormFunctions



Previous | Page 1 of 1 | Next

Programming Function Keys

Map with compass pointing to ObjectivesPurpose

Form Builder enables you to redefine the actions of function keys. This module shows you how to create key triggers to either intercept, or supplement, the usual function key behavior with which your users navigate an Oracle Forms Developer application.

Objectives

After completing this module, you should be able to:

* Define key triggers and their uses
* Program function keys
* Describe the characteristics of key triggers
* Classify key triggers
* Associate function keys with interface controls


                               

Understanding Key Triggers

When you press a function key, Forms usually performs the default function associated with that key. You can modify the standard functionality of a function key by defining a key trigger for that function key.

What is a Key Trigger?

A key trigger, like any other trigger, is a subprogram that is executed when a certain event occurs. In the case of a key trigger, the event is pressing the function key for which the trigger is defined. The trigger is usually named after the event that causes it to fire. When the key trigger is defined for a function key, the usual functionality of the key is replaced by the PL/SQL text of the trigger. In this respect, key triggers resemble "on" triggers.






Code Examples

1) This form-level Key-Exit trigger displays an alert asking the end user if he/she wants to leave the form.
SET_ALERT_PROPERTY ('question_alert', ALERT_MESSAGE_TEXT, 'Do you really want to leave the form?');
IF SHOW_ALERT ('question_alert') = ALERT_BUTTON1 THEN

EXIT_FORM; -- default functionality
END IF;
Note: If you also want to execute the default functionality of the function key, you must ensure that the key trigger includes the built-in function associated with the key.
2)The following Key-Crerec trigger disables the Create Record key:
BEGIN
NULL;
END;

Defining Key Triggers

You define key triggers in the same way that you define any other trigger. However the following two properties in the Property Palette for triggers only apply to key triggers.
Property Description
Display in Keyboard Help Specifies whether a key trigger description is displayed in the run time Keys Help window.
Keyboard Help Text Specifies the text that is displayed in the run time Keys Help window if the display in the Keyboard Help property is set to Yes. (If you want the default description to be displayed, leave this property blank).
Previous | Page 1 of 1 | 


  • Characteristics of Key Triggers

    Rules of Key Triggers

    * You cannot redefine all function keys with key triggers. Some keys are handled by the terminal or window interface manager rather than by Forms. Examples of such static function keys are [Clear Item], [Left], [Right], and [Toggle Insert/Replace].
    * You can define key triggers at all three levels: form, block, and item.
    * You can use SELECT statements, restricted built-in functions, and unrestricted built-ins.
    * Key triggers can fire in Enter Query mode.
    Note: You cannot use all built-ins in Enter Query mode.
    If you do not redefine a function key, a built-in function performs its default functionality when you press the key. Therefore, in most cases, a built-in function and a key trigger are associated with a function key. The following are a few examples of this association.
    More information, including a complete list of key triggers, can be found in Function Key Triggers in the Forms Builder documentation.


    Classifying Key Triggers

    You can distinguish among different types of key triggers. Learning these classifications will help you understand when to use key triggers.

    Types of Key Triggers

    * Function key triggers
    * Key-Fn triggers
    * Key-Others triggers

     

    Key Mapping

    Key mapping is defined by a Java resource file that you can edit with any text editor. The default resource file is FMRWEB.RES. Another resource file, FMRPCWEB.RES, has Java key mappings that resemble those on Windows. The term run-time parameter enables you to specify the use of a Java resource file other than the default.












MenuModule

 

Components of the Menu Module

What is a Menu Module?

A menu module is a hierarchically-structured object that provides a quick and easy method for operating your Forms application. Like the form module, the menu module is one of the main components of an application.
Each menu module displays as a pull-down menu. A pull-down menu comprises a set of options, displayed horizontally under the application window title. Each option can represent a submenu or an action. Selecting a submenu displays a vertical list; selecting an action executes the action.

Menu Module Components


Previous | Page 2 of 3 | Next

Components of the Menu Module

What is a Menu?

A menu is a list of related options. Each option performs a different action. You can create three menu types in Forms:
* Main menu
* Individual menu
* Submenu
Previous | Page 2 of 3 | Next



A menu is a list of related options. Each option performs a different action. You can create three menu types in Forms:
* Main menu
* Individual menu
* Submenu
-Displays horizontally in the menu bar
- Contains options (menu items) that are typically individual menus

The Default Menu

What is the Default Menu?

The Default Menu is not a separate menu module, but is built into every form module. The Default Menu includes standard commands for editing, navigating, and database interaction, such as Action-->Save.
When you build a form module, it automatically uses the Default Menu. The Default Menu is internal to Oracle Forms Developer. However you can replace the Default menu with a custom menu. A custom menu is stored in a separate module that has a suffix of .mmb. A custom menu that is exactly the same as the Default Menu, menudef.mmb ships with Oracle Forms Developer.
Note: Menudef.mmb and menudefs.mmb were omitted from the 9.0.3 release of Forms, but upgraded versions of these files will be included in the 9.0.4 release.

Examining the Default Menu

You can look at the structure of the Default Menu by opening the file called menudef.mmb. This file contains a menu module with an identical structure to that of the Default Menu. Once you have opened the menudef.mmb module, you can see its objects in the Object Navigator.
You can see that the menu module consists of a main menu (starting point), menus and menu items.

The Menu Editor

What is the Menu Editor?

The Menu Editor is a graphical design facility for laying out, modifying and viewing menu modules and their objects. You use the Menu Editor to carry out all your menu design work.

Two Ways to Display the Menu Editor

* Double-click the icon to the left of the menu module entry in the Object Navigator.
* Select Tools-->Menu Editor.

Sunday, June 3, 2012

THE_STATUSES

GET_RECORD_PROPERTY built-in
=====================
Description
Returns the value for the given property for the given record number in the given block.  The three
parameters are required.  If you do not pass the proper constants, Form Builder issues an error.  For
example, you must pass a valid record number as the argument to the record_number parameter.
Syntax
FUNCTION GET_RECORD_PROPERTY
  (
record_number 
NUMBER,
   block_name    
VARCHAR2,
   property      
NUMBER);
Built-in Type   unrestricted function
Returns  VARCHAR2
Enter Query Mode  yes
Parameters
record_number Specifies the record in a block for which you want property information.
The number must correspond to a record number.
block_name Specifies the block containing the target record.
property Specifies the property for which you want the current state. One property
constant is supported: Status.
STATUS returns NEW if the record is marked as new and there is no
changed record in the block.  Returns CHANGED if the record is marked
as changed.  Returns QUERY if the record is marked as query.  Returns
INSERT if the record is marked as insert.
Usage Notes
The following table illustrates the situations which return a NEW status.
Record
Status
Block
Status
Form
Status
Created record with no modified
fields
NEW <N|Q|C> <N|Q|C>
...and all records in current
block are NEW
NEW NEW <N|Q|C>
...and all blocks in current form
are NEW
NEW NEW NEW