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

Tony_at_santen.demon.co.uk (Tony Rothwell) wrote:
>
>
> 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.
>
> -------------------------------------------------------------------------------
> Tony Rothwell

Thanks Tony for the info and the heads up on FORMS 4.5. I understand what you are saying about the root_window controlling the other forms but not too clear on how you can avoid using the root_window. For my sake, let me give a little more detail and then you may correct or add to it if you wish.

My first form uses the root_window (I assume you have to use it since every form has one). My second form, which is called by the first form, uses a new root_window which I set up in the Forms Editor under the Window property sheet. Also, the second form contains a different menu bar than the first form. I assume in your response that 'tool-bar' is the same thing as my menu bar. So, I really can not share it.

As a side not, I did try 'Run_Product' and similar things occur as far as form control.

Another section at our facility is using FORMS 4.0 also. They got around the problem by doing the following:

1. From a menu option we do the following:

Host ('_at_form_host_test', NO_SCREEN);

This will host out to the operating system and execute the command file.

2) The command file FORM_HOST_TEST.COM contains the following line:

$RUN SYS$SYSTEM:LOGINOUT/INPUT=FORM_TEST.COM/OUTPUT=FORM_TEST.LOG This command will call the command procedure FORM_TEST.COM and execute it as a subprocess.

3) The command file FORM_TEST.COM contains the following:

$ON ERROR THEN EXIT $STATUS
$NODE = F$GETSYI("NODENAME")
$IF NODE .EQS. "ND1"
$THEN
$_at_ORA_DB:DB1 1
$ELSE
$_at_ORA_DB:DB2 2
$ENDIF
$!
$SET DISPLAY/CREATE/NODE=LAT_xxxxxxxxxxxx/TRANS=LAT
$RUNFORM40M myform.fmx username/password
$EXIT

You may also put the node stuff (ie if node=ND1 etc) in your login.com. This just ensures that the oracle logicals will be defined.

I have not tried this yet, but I will probably try it next.

Thanks for the help.

Stan Novinsky Received on Fri Jan 27 1995 - 14:31:51 CET