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

Hi Stan

What you're describing is pretty much standard behaviour for Forms 4.0 :(

I'll explain how the Call_Form built-in works: when you call a form (form B) from another form (form A), the calling form (form A) is inaccessible (all the items et al in the form are disabled); the focus is fixed in form B until you exit back to form A.

Using Call_Form, form A and B are using the same database session, and are in the same transaction (which can be controlled across multiple forms).

If this isn't what you want, consider using the Run_Product built-in to invoke form B; this runs form B totally separately from form A (with its own database session and own transactions). This may give you an unnaceptable performance hit, though.

Forms 4.5 contains a new built-in called Open_Form (I think it's called that...) that lets you open multiple forms (similarly to Run_Product, ie each form running in its own session, and all forms accessible simultaneously), but with each opened form still contained within the same MDI Document Window. This may serve you better.

If you're from a VB background, or similar, do be aware that in Oracle Forms, a single *form* can contain multiple windows (all accessible simultaneously), without hitting the limitations that using Call_Form entails. I know this is obvious, but there are some who don't realise this!

The problem you mention regarding the window containing form A moving when you call form B is explainable:
Forms 4.0 has the concept of a Root Window, where each application has a single root window that's 'shared' by all forms in the call stack (Forms 4.5 has done away with this idea). When you call form B from form A, form B "grabs hold" of the root window from form A, and moves it to the default position specified for its (form B's) own root window. Then, when you exit from form B, form A regains control of the root window and shifts it back to its original position before form B was called. This can lead to some strange looking behaviour! It also explains why sometimes a Call_Form(..., NO_HIDE) seems to function like a Call_Form(..., HIDE); it's because both forms are using the root window, and so the first form 'disappears' when the second is displayed.

The common way around this problem, is not to use the root window at all, or just use it to display a common 'tool-bar', that's used by all your forms.

Most (but maybe not all) of this stuff is described in the Forms 4.0 User's Guide.

-Tony.

In article <3g0stt$hto_at_aplcomm.jhuapl.edu>

           stan_novinsky_at_jhuapl.edu "Stan Novinsky" writes:

> 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.

Tony Rothwell                                          tony_at_santen.demon.co.uk