Forum Stats

  • 3,752,275 Users
  • 2,250,483 Discussions
  • 7,867,774 Comments

Discussions

Restrict Navigating to other form in Multi Forms application

ODev
ODev Member Posts: 9 Red Ribbon

Hi All,

Ours is multi forms application(Forms [64 Bit] Version 11.1.2.2.0). Each form is called using OPEN_FORM built-in from the main form. My requirement is to restrict navigating to another form if there any change in the current form.

For instance, there are three forms opened Form A, Form B and Form C. If the user is in Form A and did some changes and trying to navigate to Form B or C, now Form A has to raise a warning to the user that there is a change in Form A, please commit the changes before moving to another form.

Can someone please help me in implementing the above requirement?

Thanks in advance,

Dev

Tagged:

Answers

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Senior Principal Product Manager USMember Posts: 6,815 Employee
    edited Jul 6, 2021 1:21PM

    Just above your OPEN_FORM call you can do something like this:

    IF :System.Form_Status = 'CHANGED' THEN
       MESSAGE ('You must save your changes before proceeding.');
       RAISE FORM_TRIGGER_FAILURE; 
    END IF; 
    OPEN_FORM ('emp');
    

    Refer to the Builder Help for more information about:

    • SYSTEM.FORM_STATUS
    • SYSTEM.BLOCK_STATUS

    My suggestion above will only work BEFORE each form is open.

  • ODev
    ODev Member Posts: 9 Red Ribbon

    Thanks for the response, Michael.

    You are suggestion will work if Form A is calling Form B, Form B is calling Form C.

    In my scenario, Main form is calling Form A, Main form is calling Form B, Main form is calling Form C. (It is a tree node).

    So, If the user wants to Navigate to Main form from Form A or Form B after doing some changes, I want to warn the user that some changes are made, Please commit the changes.

    Thanks,

    Dev

  • SFrix
    SFrix Member Posts: 121 Bronze Badge

    Hi @ODev

    Did you try to code @Michael Ferrante-Oracle's above solution in WHEN-WINDOW-DEACTIVATED trigger ?

    I never used it but I used WHEN-WINDOW-ACTIVATED trigger to do the reverse (to do something when we navigate in the window) and it works well. So I guess in your scenario that the DEACTIVATED trigger should work.

    Seb.

  • ODev
    ODev Member Posts: 9 Red Ribbon

    Hi @SFrix

    Yes, I tried @Michael Ferrante-Oracle solution in the WHEN-FORM-NAVIGATE trigger and in the WHEN-WINDOW-DEACTIVATED trigger. Both the triggers are allowing me to navigate to another form without any warning. I want to warn the user when a user tries to navigate to another form.

    Thanks,

    Dev

  • SFrix
    SFrix Member Posts: 121 Bronze Badge

    Hi @ODev ,

    I checked the doc and I did a try and it seems you can't interrupt the form navigation. WHEN-WINDOW-DEACTIVATED trigger is well executed, it displays the message but the RAISE FORM_TRIGGER_FAILURE does not interrupt the navigation. And unfortunately you can't navigate programmatically between opened Forms.

    So not sure you can achieve what you want to do.

    Sorry.

  • Frank Hoffmann
    Frank Hoffmann Member Posts: 790 Gold Badge

    Hi,

    Forms has always a way :) So let’s try to find a way …

    First we need an indicator for the user change visible in all open Forms. I would guess you can use a global variable for this. :Global.forms_change

    (another idea would be a shared library package variable)

    Now we need a trigger to set the global to „changed“.

    Maybe a Post-Change plus a When-Window-Closed or Post-Form on Forms Level - every trigger can be used to set a global

    Now check if the global works on changes of all three forms before you execute the next open_form and pop up an error

    a post-commit trigger can set the global back to unchanged

    Frank

  • ODev
    ODev Member Posts: 9 Red Ribbon

    Thanks, @SFrix and @Frank Hoffmann . Will try your suggestions.

  • SFrix
    SFrix Member Posts: 121 Bronze Badge

    Hi @Frank Hoffmann ,

    @ODev wants to make a check not when the form is closed/opened but when the forms is deactivated/activated.

    In the scenario the 3 forms are already opened (MDI application) and the user pass from one opened forms to another one.

    The form from where the user "arrives" is deactivated and the form where the user "comes" is activated. (and not closed and opened).

    Seb

  • Frank Hoffmann
    Frank Hoffmann Member Posts: 790 Gold Badge
    edited Jul 9, 2021 7:26AM

    OK - question - will the POST-FORM Trigger fire in this scenario in the Form you leave? Try the RAISE FORM_TRIGGER_FAILURE there.

    I think I need to build this as an demo to see the site effects. I am not using Open_Form in my applications.

    Frank

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Senior Principal Product Manager USMember Posts: 6,815 Employee

    @Frank Hoffmann

    In nearly all cases of which I am aware, you cannot interrupt navigation once it has begun. In other words, any POST trigger means "AFTER" or "DURING". So, if you think of it visually; imagine you "leave" form1 and you are heading toward form2. The act of making the move fires POST. It is not possible to stop and return to the original once in flight. You must land on the target then make a decision once you have arrived.

    I think the trick is in a combination of WHEN-FORM-NAVIGATE, WHEN-WINDOW-DEACTIVATE, and WHEN-WINDOW-ACTIVATE

    I had this working at least once, but because I made so many changes trying to get it working, I forgot the correct combination. I will retest and post my findings once I get there. I will also be discussing the ACTIVATE and DEACTIVATE triggers with Dev in order to understand why I/we are not seeing the behavior I expect.

    For @ODev

    There are at least two parts to this puzzle. 1) Likely you will want to prevent additional forms from opening (new) if changes have not been saved AND 2) You want to prevent navigating to an already open form if the one the user is currently on has unsaved changes. Solving #1 is fairly easy, but for some reason #2 is not working like I expect.