Re: Forms and packages in this form

From: Jan Gelbrich <j_gelbrich_at_westfalen-blatt.de>
Date: Thu, 4 Mar 2004 16:11:05 +0100
Message-ID: <c27h47$1prase$1_at_ID-93924.news.uni-berlin.de>


[Quoted] "Mark C. Stock" <mcstockX_at_Xenquery .com> schrieb im Newsbeitrag news:CsKdnaEgecU-strdRVn-jQ_at_comcast.com...
>
> "Jan Gelbrich" <j_gelbrich_at_westfalen-blatt.de> wrote in message
> news:c2785v$1q4ue6$1_at_ID-93924.news.uni-berlin.de...
> | "Rolf Unger" <rolf.unger_at_ctilabs.de> schrieb im Newsbeitrag
> | news:32fe19ad.0403031130.6acce913_at_posting.google.com...
> | > Hi,
> | >
> | > I'm using Oracle Forms 5.0, but I guess my question should not
> | > be related to a certain version.
> | >
> |
> | BTW: Just keep in mind that 6i is bound to be desupported and 5 already
> is.
> |
> | > I have declared a package (not in the database, but in the
> | > Form-Builder under 'Program Units'):
> | >
> | > PACKAGE thisform
> | > IS
> | > TYPE t_integer IS TABLE OF NUMBER(1) INDEX BY BINARY_INTEGER;
> | >
> | > -- Type safe variables that we need only in this form
> | > v_imp_radio t_integer;
> | >
> | > -- Next 2 are needed to check if fields in file are the same
> | > -- as the user has selected with the position radio buttons
> | > n_selected NUMBER(2);
> | > n_fields NUMBER(2);
> | > END;
> | >
> | > PACKAGE BODY thisform
> | > IS
> | >
> | > BEGIN
> | > -- initialise package variables
> | > -- "shadow" state of the radio buttons in F_IMP_COLUMNS
> | > v_imp_radio(1) := 1; -- id selector
> | > v_imp_radio(2) := 1; -- unit selector
> | > v_imp_radio(3) := -1; -- origin selector
> | >
> | > n_selected := 8;
> | > n_fields := 0;
> | > END;
> | >
> | > I use them to keep track of the of 3 "on-off" radio-button groups
> | > on the control block F_IMP_COLUMNS. If I say "control" block, I
> | > mean its items are not associated with any database object.
> | >
> |
> | >
> | > If this would be a database stored package, the scope would be clear:
> | > "The first time I use a function/procedure/variable of this package,
> | > the package is loaded into Global-Area and the intialisation code
> | > between BEGIN and END of the package body is executed."
> | > Then the package variables will be valid until my session ends,
> | > until I log out.
> | >
> | > But now my Application consists of multiple forms and at runtime I do
> | > load other forms and unload this one with the package (I use
'New_Form'
> | > to do this) and later on the user may come back to this form.
> | >
> |
> | AFAIK and as afr as I can see your package, You use "local" variables
> | and no globals that could persist in other forms (i am not sure anput
it).
> | Globals can be defined anywhere.
> |
> | > What happens to my package variables, when the form is unloaded?
> |
> | They would not persist any longer.
> |
> | > Do they persist somewhere in the shared global area?
> |
> | No. Only if and as long as You would use some bind variables.
> | And they would only stay as long as the Form is open.
> |
> | >
> | > Would they be persistent if I would move the package into a library?
> |
> | AFAIK, also No. Only if You would use some bind variables.
> |
> | >
> | > Basically I don't care for persistence, I would rather like it if
> | > those package variables have the liftime of the form.
> | > Well, the package variables were in my first attempt just items in
> | > a hidden datablock, but then I realised that I would need a PL/SQL
table
> | > and I couldn't use a block anymore.
> |
> | Did You try Record Groups ? I found them very useful to make my codes
> | flexible and easy to maintain for changes.
> | PL/SQL-tables are one-dimensional, RGs can be multi-dimensional, just
like
> a
> | real table.
> |
> | >
> | > Any hints, maybe how to find something about that kind of background
> | > handling in the Forms documentation, are welcome ...
> |
> | Forms are hell bad documentated. The most complete docco is the online
> help
> | (F1).
> | It takes some time to get used to it, but then there is no place where
You
> | could find more.
> |
> | Aside of that I know only of a handful books about Forms out there.
> | It is because Forms (and Reports) never was and never will be mainstream
> | programming,
> | they are all out for the Java stuff.
> |
> | >
> | > Thanks, Rolf
> |
> | Maybe somebody else could tell You more details,
> | greetings
> |
> | hth, Jan
> |
> |
>
> definitely upgrade to 9i
>
> starting somewhere with v6 forms started to support shared (persistent)
> library code, so the package state would persist across forms -- although
i
> don't recall if this required putting the code in a library or not
>
> ;-{ mcs
>
>

Generally I would fully agree for Forms 9i, except for one thing: Forms 9i does not support C/S (2tier) environments any longer, 6i was the last version that did.
And on some sites (mine for instance), people decided not to move to 3tier, and then You are stuck with 6i.
Maybe old fashioned, but it works.

Greetings, Jan Received on Thu Mar 04 2004 - 16:11:05 CET

Original text of this message