Forms 6i, Form calling a Form without new form canvas being displayed

We have a large Oracle Forms 6i and Reports 6i application with about 2000 Forms and 800 Reports; so we know a little about Oracle programming. We have a situation where one Form calls another and we wish that the change in Form would not cause the screen canvass of the called Form to be displayed. We have one Form that calls another Form (perhaps) 100 times and the problem we are describing causes the screen to 'flicker'; which is irritating. How can we avoid this screen flickering - Please.
DMay1Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

schwertnerCommented:
"we wish that the change in Form would not cause the screen canvass of the called Form to be displayed"
What do you mean here? You call a new Forme to display one of the canvases. There is no other reason to call a Form.

OPEN_FORM to Invoke Additional Forms
This built-in procedure opens another form in a modeless fashion; that is, a
user can freely switch between open forms. You can open a form within the
same transaction scope or within a new transaction scope.
Syntax
OPEN_FORM(’form_name’, activate_mode, session_mode, data_mode,
paramlist);
You can set the parameter "activate_mode" Either ACTIVATE (the default) or NO_ACTIVATE
If you set session_mode to SESSION
the changes in the called form will not cause messy messages for the calling form

If you would like not to see the the CALLING form and have no access to it  
call the new form so:
CALL_FORM(’form_name ’, display,
switch_menu, query_mode,
data_mode, paramlist);

If you would like never to return to the calling form
call the new form so:
NEW_FORM(’form_name’, rollback_mode,
query_mode, data_mode,
paramlist);
0
DMay1Author Commented:
Firstly, many thanks for your prompt reply. The reason that we have built a called-Form within which we have many table updates etc, is that we have been building a very large application where there is a large and increasing number of Forms that capture data (from humans and other processes) that need to effect, or expect to effect many of a series of possible table updates. To try and keep the software maintenance and development to a minimum, we built a called-Form that could be called from as many places as required, within which all of the possible table updates could be catalogued. There is no requirement in this called-Form for any screen activity.

We cannot use Open_Form as we do not want another session , which would still cause the flashing and the called Form would not automatically Exit.

We cannot use New_Form because we always want to return to the calling-Form.

So we use Call_Form so as to be able to automatically get back to the calling-Form. However, we are under the impression that there MUST BE at least one variable field in the called Form that is displayed.  We have tried using the HIDE/NO_HIDE values in the 'display' parameter and this makes no difference. Notice with this, it is the calling-Form screen image that is under control, not the called Form screen image.  Is there a way in a Form of not having any variable field that HAS to be shown on a screen image?

Best Regards
DMay
Johannesburg
0
DMay1Author Commented:
Our tame geek, nurd, techy thinks that my explanation above is a bit 'flowery' and has asked me to include his versiion here, which reads:-

We have a FormA that calls FormB. FormB does a number of database table updates using a database record written by FormA, the identity of which is passed from FormA to FormB. There is no user interaction in FormB. Once FormB is completed, it automatically exists back to FormA, where the user has control once more.

The problem we have is that sometimes, FormA needs to call FormB more than 100 times, which causes a 'flickering' of the screen as FormB executes. This looks 'tacky', so my question is, is there a way for FormB to execute behind FormA?

Jim Sinclair
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

schwertnerCommented:
I wonder over this passage:

<We have a FormA that calls FormB. FormB does a number of database table updates using a database record written by FormA, the identity of which is passed from FormA to FormB. There is no user interaction in FormB. Once FormB is completed, it automatically exists back to FormA, where the user has control once more.>

It is either wrong explanation or you do not understood the real functionality of FormB.

Forms are intended for interaction with users. If you have no interaction with user you do not need forma. You can invoke a procedure which will do the job explained in your comments.

0
AlbertYouCommented:

Hi DMay1:

I would like to suggest you to move the SQL update statements as well as the business rules from form B into a PL/SQL library and/or a database package, and then the library/package can be reused in all forms/reports.


Albert.
 
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
schwertnerCommented:
What in fact was my suggestion.
0
DMay1Author Commented:
We are new to this site. It has occurred to us that by selecyting 'Accepted' against AlbertYou, we may have caused Albert to get the points and not yourself. If this is so, then we apologise after all of the time you spent with us and the issue. Please show this to the Helpdesk and get the situation corrected if it is wrong.

Regards
DMay
Johannesburg
0
AlbertYouCommented:

Hi schwertner,DMay1 :

I agree with you.
You may take the points back from me if you would like to do so.

Albert.
0
DMay1Author Commented:
To  Schvertner (and Albert)

Many thanks, we spent the Xmas an New HYear Holiday;doing two things; on your recommendation. The first step was to take the active parts of FormsB and making a stored procedure out of it; this was very large task as the actual contents of FormB were extensive. Then we ran an AWK program/scrip against our source code library to obtain a list of FormA(s) that used to call FormB. Each of these FormsA was changed to access the stored procedure version of FormB. the old FormB was removed to a safe place and a 'Compile All' (Okay Generate All, but I come from the old school where we had directories and source decks) was run to confirm that we had completed the overall exercise.

The 'screen flickering', which was our original problem has gone and the updating of the online database tables is FAST; even to the extent that  we though the update components had no run!

We have learned another lesson regarding called Forms; Many Thanks.
 
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.