Re: FORMS V4.0 - Form calling a Form?
Date: 19 Jan 1995 14:42:18 GMT
Message-ID: <3fltoa$snm_at_theopolis.orl.mmc.com>
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 Dorms 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
Received on Thu Jan 19 1995 - 15:42:18 CET