Wendy and the Oracle

I have a form in which I reuse the window. I have 5 canvases, each contain a block. On the first canvas I have 4 buttons to navigate to the blocks. This is what happens:
- I enter the form
- I press the first button to go to the second block
- First, the PRE-BLOCK trigger of the second block fires
- Then the WHEN-BUTTON-PRESSED trigger of the first button fires
- Then the PRE-BLOCK trigger of the third block fires (!)
- Then the PRE-BLOCK trigger of the fourth block fires (!)
- Then the PRE-BLOCK trigger of the fifth block fires (!)
- Then the PRE-BLOCK trigger of the second block fires again (!!!)

This only happens once, no matter which button I press. When I navigate back to my original block and then press another of the 4 buttons, only the PRE-BLOCK of that particular block fires and after that the WHEN-BUTTON-PRESSED trigger and that’s it.

I ran into this trying to change the window title in the WHEN-BUTTON-PRESSED trigger of the button and the PRE-BLOCK trigger kindly changed it back because it was fired before and after the WHEN-BUTTON-PRESSED trigger….
I have posted this on OTN here.

[Update 28-12-2005]
I found out that the generator preference BSCSCP is not implemented consistently in the Designer library.
I created a Service Request (They are no longer called TARs) in which it said this:

Situation:
One form, one window with 5 canvases on top of eachother. When one is visible the rest is not. First canvas contains the master block, the other 4 contain detail blocks, all on the same level (directly under the master).
The first canvas has 4 buttons to navigate to the other 4, the 4 other canvases have one button to navigate back to the first canvas.

Generator preferences:
BSCSCP: F
BSMOFF: E
BSMON: A
BSQENP: Y

When starting the form the following happens:
- the on-populate-details query does not query the details, because the 4 canvases are not visible.
- the when-new-block-instance trigger is fired, calls CGBS$NEW_BLOCK but since P_TO_BLOCK is equal to CGBS2$.GET_NAV_FROM_BLOCK it does nothing.
All detail blocks are NONCOORDINATED.
Conclusion: details are not queried. This is the behavior I want.

When using one of the buttons to navigate to another canvas, the following happens:
- the when-new-block-instance trigger fires, and since P_TO_BLOCK != CGBS2$.GET_NAV_FROM_BLOCK, CGBS$.COORD_VISIBLE_BLKS(P_TO_BLOCK) is called.
This procedure loops through all blocks, and for the NONCOORDINATED blocks (there are 4 of these now) it does roughly the same
as in the ON-POPULATE-DETAILS trigger, BUT on line 80 of package CGBS$ this line is different:
CGBS2$.GET_BLOCK_WINDOW(current_block) = event_window
My form has one window, which makes this condition true at all times and which means that for all 4 detail blocks the
details are queried, even when the canvas they are on is not visible.
What I expected was that Only the block I navigating to is queried, and the others are not, until I navigate to them.
The result of this behavior is that the block triggers for all blocks are fired which results in unwanted behavior.
For example, the title of the window is changed in the when-new-block-instance trigger, and thus wrongly set.

After this, all details have been queried, all blocks are COORDINATED and behavior is as expected, until a different row
in the master block is selected and the whole process starts over.

I think that the following code (lines 76-84, CGBS$COORD_VISIBLE_BLKS)

elsif ( CGBS2$.GET_COORD_STYLE = ‘F’ )
then
if ( CGBS2$.IS_TREE_VISIBLE(current_block)
or
CGBS2$.GET_BLOCK_WINDOW(current_block) = event_window
)
then
CGBS$.QRY_ONE_BLK(current_block);
end if;

should actually be

elsif ( CGBS2$.GET_COORD_STYLE = ‘F’ )
then
if ( CGBS2$.IS_TREE_VISIBLE(current_block) )
then
CGBS$.QRY_ONE_BLK(current_block);
end if;

Like it is in CGBS$COORD_RELATION (lines 451-463)
(My apologies if the line numbers don’t match, I used Textpad to determine them)

Which describes best what I have found so far.
I will update this post when Oracle have contacted me…..

[update]

Oracle have admitted that the code is not consistent, but no patch will be written because it could affect too many applications already relying on this behavior. I left it at that since it’s not really important anyway