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.
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.
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).
· 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 )
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:
· Caps Lock+
· Control+ (default)
If you do not want to enable a KEYMODIFIER, set the parameter value to nothing.
The first panel option has the same functionalities than the version 1.
To see the new functionalities, click the Next Options… button.
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
· Unzip the FJTable_2.zip 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
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).
· 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.
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
PC$Module IN VARCHAR2,
PC$Block IN VARCHAR2 DEFAULT NULL
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:
EXECUTE PKG_FJTABLE.Remove_Object( ‘EMPLOYEES’, ‘EMP’ ) ;
This is an autonomous procedure, so you do not have to commit and you can use it inside of your forms.
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).
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.
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.
· 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 NAME X_POS
-- Incorrect setting --
ITEM NAME X_POS
ITEM_2 140 --> in the object navigator, drag this item after ITEM_3
· 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 --
Message( LC$ErrType || '-' || TO_CHAR(LN$ErrCode) || ': ' || LC$ErrText);
Raise form_trigger_failure ;
End if ;
· 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.
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 “email@example.com”