Re: Forms 4.5 Excessive Stacking

From: Neville Sweet <sweet.neville.nj_at_bhp.com.au.no_junk_email>
Date: 24 Aug 1998 02:51:55 GMT
Message-ID: <01bdcf09$2c27c0e0$483c1286_at_itwol-pc3963.itwol.bhp.com.au>


Valery,

[Quoted] The only reply I have had thus far is from Kathy Stachkunas, as follows:

Modify the procedure which calls the forms to include something like below:

Procedure Call_Go_Form ( v_form_name varchar2 ) \ is

   fid FormModule;
begin

	fid := find_form(v_form_name);
        if id_null(fid)
       then  call_form(v_form, HIDE, DO_REPLACE );   -- open the form
       else  go_form(fid);  -- go to old copy
	end if;

end call_go_form;

Changes can be made very easily to do the the same thing with new_form and open_form.

Unfortunatley, Oracle Help on Go_Form mentions a significant restriction: The target form cannot be a form that is currently disabled as a result of having invoked another form with CALL_FORM.

This would indicate that Go_Form is intended to move between multiple active forms, which were created with Open_Form, and that the current form is not actually removed from the stack.

The advice does, however, suggest some options. Once the presence of a form has been established using Find_Form, I can repeatedly Exit_Form back through the stack until I reach the required form (controlled using Globals). This is provided there are no outstanding changes in forms in the stack - which we actively avoid anyway because of the Post-only restriction imposed on child forms. Another condition is that the operator requests a form already in the stack before memory is exhausted and the PC crashes - sounds reasonable. Another application issue is that if I trash all forms in the stack back to the one they want then I may scrap something in the stack that the operator still wants to use. An alternative may be to prevent them from calling a form already in the stack, and tell the operator via a message or Alert to hit the 'Exit' button until they get back to the required form.

Some food for thought...

By the way, the advice came via the Developer2000 listserver. If you want to subscribe, send e-mail to: listserver_at_developer2000.com include only the line: subscribe d2k
in the message body

Valery A. Sorokin <vsorokin_at_dd.ru> wrote in article <35D97D28.36611407_at_dd.ru>...
> Unfortunately, in Forms 5.0 on Win95 if you will use many CALL_FORM in
your
> application, then your application will crush :(
>
> It will be work slowly and slowly... (disk i/o grow and grow)...
> and crush (application).
>
> Can somebody find any solution? Any help would be greatly appreciated.
>
> Neville Sweet wrote:
> >
> > Hi,
> >
> > I'm looking for suggestions on avoiding an excessive stack of forms
created
> > by using CALL_FORM.
> >
> > Our application has multi-record List and single-record Detail programs
> > written as separate forms. A List calls a Detail form with CALL_FORM.
Using
> > CALL_FORM allows the detail form to return to the list by exiting the
> > stacked program.
> > In the detail form you can also use the menu and replace the Form with
> > another (which uses NEW_FORM).
> > This form may itself be a list with an associated detail form. Repeat
this
> > over a number of hours or days and sooner or later the PC will run out
of
> > memory. Even if you don't, it appears confusing to an end-user when
they
> > hit Exit and end up in one or more screens that they were in hours
earlier.
> >
> > Anyone have some ideas on how this may be avoided without redesigning
the
> > application?
> > We have a large number of production programs, so I'm searching for a
> > solution that doesn't involve changing every program. We use a run-time
> > library procedure when calling forms (which for example ensures you
don't
> > select the same form you're in).
> > I am unaware of any mechanism within Forms to detect when an instance
of a
> > form is already stacked, for instance, or to discover which forms are
> > stacked, or even how many.
> >
> > Admittedly this is a design problem not restricted to Oracle Forms, so
if
> > anyone has any general solution I would appreciate hearing about it.
> >
> > Thanks,
> > Neville Sweet.
> > Email: sweet.neville.nj_at_bhp.com.au.no_junk_email
>
> --
> Valery A. Sorokin
> ProSoft, Russia, Moscow, Information Systems Division
> Phone: +7 (095) 234 0636 (6 lines) FAX: +7 (095) 234 0640
> E-mail: vsorokin_at_dd.ru OR vsorokin_at_prosoftmpc.msk.su
> http://www.dd.ru
>
Received on Mon Aug 24 1998 - 04:51:55 CEST

Original text of this message