hrlp FRM-40106 No navigable items [message #261669] |
Thu, 23 August 2007 05:24  |
DaveCot
Messages: 3 Registered: August 2007 Location: Manchester, UK
|
Junior Member |
|
|
Hi,
I have a problem with a form that i am currently working on.
I am gettting the FRM 40106 no navigable items error when the form opens
but have been unable to rectify the problem by putting a dummy item on
the form. I have also checked that at least one item in each block is
enabled and visble.
I'm wondering is ther any rules around block ordering etc or queries
populating the forms blocks that could cause this?
I'm really stuck and would greatly appreciate some advice.
Dave
|
|
|
|
Re: hrlp FRM-40106 No navigable items [message #261681 is a reply to message #261676] |
Thu, 23 August 2007 05:49   |
DaveCot
Messages: 3 Registered: August 2007 Location: Manchester, UK
|
Junior Member |
|
|
Soumen,
My form navigates to a block, then to another, which points it back to the original block (i'm not sure why it has been developed this way). These two blocks contain both text and display items.
There is also another data block which is not visible, a ctl_blk and a block for the toolbar although non of the last three are referenced in the block navigation.
I've tried a few things but dont seem to be able to fix it.
Dave
|
|
|
|
Re: hrlp FRM-40106 No navigable items [message #261956 is a reply to message #261669] |
Fri, 24 August 2007 02:57   |
DaveCot
Messages: 3 Registered: August 2007 Location: Manchester, UK
|
Junior Member |
|
|
David,
Yes i inherited if from the developer who was on the project before myself and my senior developer arrived. The senior devloper is unfortunately off on Annual Leave now and he has broken the application which was orginally 6 canvases all with different functionality into 6 seperate forms but had left a few residual bugs for me to investigate.
I have actually now fixed the problem but explain below how.
Basically after a lot of careful de-bugging and another check of the help menu description of the FRM 40106 error, below is the explanation with a few bits of un helpful detail (such as calls to other unimportant blocks) removed.
1. When the RAG (rag shows the jeopardy status of a particular budget) form was called from the main form it checks the parameters came across ok then performs the following
go_block('PP_UNIT_RAG_OVERALL');
clear_block;
execute_query;
2. PP_UNIT_RAG_OVERALL is the master table and as such the clear_block call triggered ON-CLEAR-DETAILS trigger which in turn calls procedure CLEAR-MASTER-DETAILS. These all ran fine and dropped back into the wrapper in step 1, execute-query is fired.
3. PP_UNIT_RAG_OVERALL.ON-POPULATE-DETAILS trigger activates with the following script
--
-- Begin default relation declare section
--
DECLARE
recstat VARCHAR2 (20) := :System.record_status; /* checks if any changes have been
made to the block in system cursor (should be no if queried from base table)*/
startitm VARCHAR2 (61) := :System.cursor_item; /*determines which item the system
cursos is lookinga t currently*/
rel_id Relation; /* Variable to pass block/trigger name etc to error handling
prog unit 'raise_error' */
sub_module varchar2 (100) := 'pp_unit_rag_overall.on-populate-details'; /* ignore,
part or error handling */
--
-- End default relation declare section
--
--
-- Begin default relation program section
--
BEGIN
IF ( recstat = 'NEW'
or recstat = 'INSERT') THEN /*checks if System.record_status
identified unvalidated changes in the block this passed fine*/
RETURN;
END IF;
--
-- Begin PP_UNIT_RAG detail program section
--
IF ( (:PP_UNIT_RAG_OVERALL.PP_UNIT is not null)
or (:PP_UNIT_RAG_OVERALL.PP_RAG_PERIOD is not null)) THEN
rel_id := Find_Relation ('PP_UNIT_RAG_OVERALL.PP_UNIT_RAG_OVE_PP_UNIT_RAG');
Query_Master_Details (rel_id, 'PP_UNIT_RAG_REVIEW');
END IF;
END;
4. Query_Master_Details is called and the parameter 'PP_UNIT_RAG_REVIEW' passed in by the above trigger is named DETAILS in the called procedure, and the below commands are executed.
begin
reldef := Get_Relation_Property (rel_id, DEFERRED_COORDINATION);
/* = This built-in determines if the detail is to be immediately coordinated
with the master or only when operator navigates to detail block. In my
instance it's the latter and FALSE is returned */
IF reldef = 'FALSE' THEN
Go_Block (detail);
Check_Package_Failure;
end if;
end;
5. It was at this point that CHECK_PACKAGE_FAILURE performed
IF NOT ( Form_Success ) THEN
RAISE Form_Trigger_Failure;
END IF;
Which basically checks if the previous action (go_block in this case) was successful. It was here that the no navigable items fault was being raised.
6. From here I checked some items in block PP_UNIT_RAG_REVIEW from within the object navigator (none of its items are visible anywhere on the form) and moved a navigable item (text_box as display boxes don't work apparently) to the top of the block, and set the following properties:
Keyboard navigable = yes
Enabled = Yes
Visible = Yes
Canvas = RAG_CANVAS
And hey presto it worked.
NOTE:
The block PP_UNIT_RAG_REVIEW was not included in the block navigation form form level. And as such was not included in the PREVIOS NAVIGATION BLOCK or NEXT NAVIGATION BLOCK property at block level.
This only worked once the text item was assigned to a form so it had to be hidden (as advised in most related threads)
The use of DEBUG, DEBUG WINDOWS, (stack & variables) from the forms application toolbar during debug was very useful here to see what was values were assigned to the local variables as the process passed me between all the various triggers and prcedures. I am still learning all these things so these may be useful tips for any new comers.
I hope this thread may help others in the future.
[Updated on: Sun, 26 August 2007 21:55] by Moderator Report message to a moderator
|
|
|
|