Re: Forms and packages in this form

[Quoted] Thanks for your replies, guys!

1. Upgrading I tried to convert my Forms to 6i some months ago. It was a absolutely frustrating process ... and I couldn't complete it. [Quoted] The major problem were some Combo-Boxes, that suddenly disappeared during runtime (to be correct they never appeard on the forms, i did only see the gray background where I had a combo box with version 5). Other Combo-boxes were visible and functional, and I compared the settings of these items with the invisable ones: I swear, I did not see any difference in the Properties! I found some upgrade hint saying that the only reliable way would be to create the items, especially the combo boxes new from scratch in the 6i form builder, but this did not work for me. (If I remember correctly, the compiler was complaining that no items were in the list, I filled it dynamically at runtime. In Forms5 this was only a warning when compiling, but in 6i it did not build the fmx file.) [Quoted] If I changed the combo box into a list box, it always appeared, but to be honest i needed the insert functionality of the combo box.

  Not so sure about the details of this experience, but take this as an   explanation why upgrading is a synonym for "horror" for me =8-O

b) Global Variables
  I've read an article by Steven Feuerstein a while ago, where he   basically discouraged to use the Forms/Reports Globals.   :GLOBAL.somevar, Name_In(...) and Copy(..).   His alternative was to write a PL/SQL package stored in the database   together with some accessor functions to read and write the   package variables.
[Quoted]   That made pretty much sense to me, especially because I can then use   the editor of my choice and a Source-Control System that is effective   and not disturbed by the compilation dates, that are in the fmt files.   Of course I need the right to create packages in the database, but   that's not an issue for me: I always managed to convince the database   admin.

Well maybe I will have a look at record-groups, if they will give me the functionality, that I need.
[Quoted] On the other hand, if you say that the variables in my forms package will loose scope, if the form is unloaded, then my solution just gives me the functionality that I need.

Rolf.

"Jan Gelbrich" <j_gelbrich_at_westfalen-blatt.de> wrote in message news:<c27h47$1prase$1_at_ID-93924.news.uni-berlin.de>...
> "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'):
> > | >
> > | > [ ... ]
> > | >
> > | > 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.
> > |
> > | [ ... ]
> > |
> > | >
> > | > Would they be persistent if I would move the package into a library?
> > |
> > | AFAIK, also No. Only if You would use some bind variables.
> > |
> > | [ ... ]
> > |
> > | 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.
> > | [ ... ]
> > |
> > | 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 Fri Mar 05 2004 - 15:55:36 CET