Re: FORMS V4.0 - Form calling a Form?

troyt_at_sun.com (troy trimble) wrote:
>
> In article 6hk_at_aplcomm.jhuapl.edu, Stan Novinsky <stan_novinsky_at_jhuapl.edu> () writes:
> > I am using FORMS V4.0 on OpenVMS V6.1. I created two separate
> > Forms with customized menus by using the Menu Editor. I added a
> > RUN_PRODUCT (FORMS) statement in the Command Text Field of the Menu
> > Editor to call the second for one of the menu items in the
> > pull-down menu. When I run the first Form and select the option to
> > start the second Form, the second Form starts but the following
> > things happen:
> >
> > a. The second Form starts and the focus becomes fixed in the
> > second Form.
> > b. When I move the mouse from the First Form to the second Form,
> > the mouse turns into the "in progress" clock symbol and the
> > form does not completely redraw.
> > c. When I exit the Forms by using the "magic menu" exit in the
> > pull-down menu, I receive a %SYSTEM-F-ACCVIO (access
> > violation) error followed by routine listings.
> >
> > Q1. Is there a bug in the FORMS procedures that does not allow the
> > RUN_PRODUCT command to work with FORMS ?
> > Q2 Has anyone else found a problem with using customized menus
> > that are used to invoke other menus ?
> >
> > As a note, I tried the CALL_FORM routine instead of RUN_PRODUCT
> > and I got even more bizarre results which I will not go into at
> > this time.
> >
> > Q3. Has anyone found a way to call a Form from a Form?
> >
>
> I work on a project where we are developing a couple of very large
> Forms 4.0-based applications using Oracle 7.0 for Sun Solaris and Forms
> 4.0.12. I use CALL_FORM(form_name, HIDE, DO_REPLACE) to invoke child
> forms. This hides the parent form while the child is running and the
> child will use its own menu instead of the parent's. This works fine
> on the most part, except for an annoying screen redraw before and after
> each child form that includes briefly displaying higher-level parent
> forms that are hidden at the time. Also, due to a bug in 4.0.12, if you
> exit a child form with uncommitted changes, Forms would often crash.
> I fixed this by creating a KEY-EXIT trigger with a CLEAR_FORM followed
> by EXIT_FORM. CLEAR_FORM would ask the user if he/she wants to save
> changes if necessary and commit if the user selects Yes. As long as
> the user doesn't select Cancel, there will be no uncommitted changes by
> the time EXIT_FORM is called, thus bypassing the crashing problem.
>
> As far as the menus go, I basically use the default Oracle menus so I
> don't have an answer for that.
>
> Good luck,
> TT
>
> --------------------------------------------------------------------------------
> Troy W. Trimble -- troyt_at_csdc02.orl.mmc.com -- Engineer, Software Development
> Martin Marietta Corporation -- Civil Information Systems -- Orlando, Florida
> --------------------------------------------------------------------------------
>

 Thanks for the tips. We may be able to use some the methods  mentioned above. We are using Forms V4.0.12.4.3

 Our requirements will REQUIRE a parent form to call a child form  and then, the child from to call other child forms. The parent  and all child forms may be required to be displayed on the  same screen at the same time (similar to Motif allowing multiple  windows to be displayed). I tried this as a first step but got  strange results.  

 I created two forms each with customized menus. In the customized  menu of the first form, I have a menu item that contains  four submenu items. Off of the first submenu I execute the  CALL_FORM PL/SQL command - CALL_FORM (form2, NO_HIDE, NO_REPLACE,  QUERY_ONLY). This is what happens:

    When I run the first form, which contains TEXT_FIELDS and BUTTONS     it starts up fine. When I select the submenu item from my     customized menu containing the CALL_FORM,     the first form is moved to the upper left hand corner of the     screen and is not accessible (that is, I can not grab the     border and move the form to another area of the screen unless I     restart the window manager of my session). When I exit the second     form, the first form is moved back to the starting position.     In addition, when the first form is made the active form     while the second form is up, the items in the first form such as     BUTTONS are stippled out and become inaccessible.

 I don't know if anyone else has had the same problems as I have  or not. If so, please post a follow up here.

 From this point, I do not know how we will get around the problem.  Hopefully, the next release of forms will correct some of these  problems. Otherwise, we may go to a Motif GUI that calls forms  and uses PL/SQL.