FJTable Oracle Forms tool 2.1

(persistent version)


Home page




What’s up in this version ?

Objects provided with this tool

How the user can invoke the FJTable options panel ?

Some screen shots samples

Installation steps

Test with your own form

Special settings

Translation strings

Known issues

Need your feedback



 French version




1.    Purpose


This tool allows multi-lines blocks to look like a Java Swing Jtable and store/retrieve initial and user settings.

Each time the user re-load a form, the blocks are automatically displayed with the last user settings.


In the Forms application, when the cursor is located in a multi-lines block, user can perform the following actions:


q       Swap columns

q       Increase / decrease the size of each column

q       Sort the block on every based column (ASC/DESC)

q       Change the item prompt

q       Store the user's new settings

q       Read the user's last settings

q       Read the initial (design) settings


The settings are stored in two Oracle tables:


Ø      FJT_BLOCK           that store bloc values

Ø      FJTABLE     that store item values


Each raw is identified by a USER_ID (because each user can save/retrieve his own settings)

The USER_ID comes from the :PARAMETER.USER_ID Forms parameter.


The USER_ID : 0 is reserved for the initial (design time) settings. Do not give this number to a user.


Default value for this parameter in the object group is 1




This tool has been tested with the following configurations:


·        Forms 9i and Database 9i

·        Forms 10g and Database 10g



If you still use a previous version, do not forget you can download (for test) more recent versions from OTN.




2.    What’s up in this version ?


Bug correction


q       Migrated form for previous version (6i and previous).

Someone tell me that, when a previous form (6i) is migrated, the database COLUMN_NAME property is left blank.

A parameter has been added (PM$INITIAL_VERSION) to indicate the initial (before any migration) version.

The default is : 9.

If form comes from a migration, indicate in this parameter a number less than 9.




q       12/08/2005 First release (Creation).



3.    Objects provided with this tool


·        A PL/SQL library wich contains one package ( fjtable_2.pll )

·        An object library wich contains one object group ( obj_fjtable_2.olb )

·        A SQL script to create the database objects ( fjtable_install.sql )




4.    How the user can invoke the FJTable tool options panel ?


When the cursor is located in a multi-lines block, users can invoke the FJTable tool options panel by a double-click in any column of the block. If a KEYMODIFIER is specified, users must press this keyboard key at the same time they double-click.


If the double-click functionality is already in use in your form, you can add a KEYMODIFIER to be sure there will not be any interference with your own code.


The KEYMODIFIER is read from the Forms parameter :  :PARAMETER.PM$SHIFTSTATUS


The possible values can be:


·        Shift+

·        Caps Lock+

·        Control+ (default)

·        Alt+

·        Command+

·        Super+

·        Hyper+


If you do not want to enable a KEYMODIFIER, set the parameter value to nothing.



5.    Some screen shots samples:



The first panel option has the same functionalities than the version 1.

(see the doc of version 1)



To see the new functionalities, click the Next Options… button.



Users can change the item prompt of the selected column






They can also:


q       Save the current settings into the database

q       Load the last saved settings from the database

q       Load the initial (design time) settings from the database





6.    Installation steps:


·        Download the file


·        Unzip the file


·        Open the fjtable_install.sql


Ø      adjust the CREATE TABLE statements to fit your own specifications

(tablespace, initial extent, next extent, etc.)


Ø      Run the fjtable_install.sql


·        Compile the fjtable_2.pll library



Data security


If you are “hot” with data security, do the following steps:


q       Create a special schema to store the two tables and the PKG_FJTABLE package

q       Create synonyms on tables and package

q       Grant SELECT on tables to users

q       Grant EXECUTE on package to users


Then, users can see the datas (FJTable tool read datas from forms), but cannot perform any other operation.

( the writing process is done in the PKG_FJTABLE package).




7.    Test with your own form


·        Open your form module

·        Attach the fjtable_2.pll library

·        Open the obj_fjtable_2.olb objects library

·        Drag the GRP_FJTABLE_xxx object group to your Object group node (click the REFERENCE option)

(Depending on the coordinate system currently used in your form, drag the corresponding Object group)







Ø      Move the BL_JFMENU block to the end of the blocks list in the object navigator

Ø      Move the CV_JFMENU canvas to the end of the canvases list in the object navigator


·        Edit the When-New-Form-Instance trigger to add the call of the init procedure:




     PC$Can_Resize_Window => :PARAMETER.PM$RESIZEWINDOW,

     PC$Can_Resize_Canvas => :PARAMETER.PM$RESIZECANVAS,

     PN$Initial_Version   => :PARAMETER.PM$INITIAL_VERSION

 ) ;


If the module comes from a previous release migration process (e.g. Forms6i), enter a number less than 9 in the PM$INITIAL_VERSION


·        Compile all and run the form.



When an existing form is modified


If you modify a block in a form, the synchronization between item properties and corresponding stored datas is lost.

So you have to remove corresponding raws from the tables.


To remove datas for a block, you can use the PKG_FJTABLE.Remove_Object() procedure



  PROCEDURE remove_object


     PC$Module IN VARCHAR2,


  ) ;


If you do not pass the PC$Block argument, all the blocks for this module are removed.




Assume you have modified the EMP block of the EMPLOYEES module, run the following instruction:




This is an autonomous procedure, so you do not have to commit and you can use it inside of your forms.



User identification


Because FJTable tool stores settings for each user, they must be identified by a unique user ID.

This user ID is passed from form to form through the USER_ID parameter, so you may have to adapt your OPEN_FORM(), NEW-FORM() and CALL_FORM() existing calls.

The 0 value is reserved to store the initial settings. Do not attribute this value to a user.

If you do not implement unique user Ids, all users will see the same settings (default USER_ID parameter value is 1).




8.    Special settings


If you already use a When-Mouse-Doubleclick block or item trigger:


·        Set its Execution Hierarchy Property property to : fire after parent

·        Be sure that the PM$SHIFTSTATUS parameter contains a key modifier.




9.    Translation strings


You can translate some strings into your own language.


The strings that can be translated are label, hint and tooltip of the FJTable tool option panel’s buttons and several messages displayed in the status bar.


The translation strings are stored in both PKG_JTABLE library’s package specifications and body.




10.                      Known issues


·        As it is not possible (with the actual Forms version) to modify at run time the properties of graphic items like Frames, do not use them with your multi-lines blocks.

When the user increases the size of columns,  this automatically increases the size of the canvas but the frame does not !


One solution is to replace the frame with a single straight line at the top of the block.


·        Items order in the object navigator

Items in the object navigator must be in order by X_POS ascending



-- Correct setting --


ITEM_1                50

ITEM_2                100

ITEM_3                140


-- Incorrect setting --


ITEM_1                50

ITEM_2                140    --> in the object navigator, drag this item after ITEM_3

ITEM_3                100


·        For blocks that do not have scrollbar, a FRM-99999 message is displayed in the status bar.

Because the move of the scrollbar is the last action performed by the Move_Item() procedure, all seem to be right.

I think the problem is with the Get_Block_Property( …, BLOCKSCROLLBAR_X_POS ) built-in when no scrollbar exists for the block.


If your form contains multi-lines blocks with no scrollbar defined, modify your existing ON-ERROR form-level trigger or add it:



  LN$ErrCode  Number := ERROR_CODE ;

  LC$ErrType  VArchar(3) := ERROR_TYPE;  

  LC$ErrText  Varchar2(256) := ERROR_TEXT ;


  If LN$ErrCode = 99999 and LC$ErrText like '%1413%' Then

      -- Error on Get_Block_Property( ..., BLOCKSCROLLBAR_X_POS ) --

      -- If Block does not have Scrollbar defined --

      Null ;


     Bell ;

     Message( LC$ErrType || '-' || TO_CHAR(LN$ErrCode) || ': ' || LC$ErrText);

     Raise form_trigger_failure ;

  End if ;

End ;



·        Because it is not possible to retrieve Option buttons from a Radio Group, this item type cannot be moved/resized.

When a bloc contains a Radio Group item, the FJTable tool Panel cannot be invoked.




11.                      Need your feedback


I have tried this tool with a certain amount of forms and it seems to go right.

However, with your own forms, you might get bugs.


This version does not take into account the SHARE_LIBRARY_DATA calling form’s functionality.


Please, send me your feedback by email at “