Re: Forms and packages in this form

Some comments from my experiences added inline ...

"Rolf Unger" <rolf.unger_at_ctilabs.de> schrieb im Newsbeitrag news:32fe19ad.0403050655.4aff0303_at_posting.google.com...
> Thanks for your replies, guys!
>
> a) Upgrading
> I tried to convert my Forms to 6i some months ago.
> It was a absolutely frustrating process ... and I couldn't complete
> it.

Our move from 5 to 6i is not too long ago (we were told that they decided to stay 2tier).

My first tests were frustrating, too: Some smart guys said "You only have to recompile all and that´s it".

It wasn´t. Object Groups could not be found etc, the reference Form could not be found,
so that the item layout defaults were all lost, and we got items of hight 0 ...
(Maybe this is what You call "they disappeared").

We figured out that our problems could all be solved by setting the working paths in DS6i
properly; we had our files in a different directory layout which did not conform to
the DS6i defaults. This was why some files could not be found. After making those corrections (only a few), all forms did recompile (with some very few exceptions).

> 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.)

When we use Combo/List boxes or LOVs, we base them on Record Groups, that is by CREATE_GROUP_FROM_QUERY built-in. Then the lists items are populated by POPULATE_LIST. Inside a form, those actions are put in a PU and invoked by WHEN-NEW-FORM-INSTANCE trigger. If needed, the PU is called through some other triggers.
This all did recompile with no problems, provided proper path settings.

> 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.

Indeed, :Globals are some sort fo things that can be used but should only be used
if really necessary and then with care.

> 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.

When I started using Forms, I only used RGs for populating list items, but they are also helpful for many more purposes ... I once wrote a small SQL generator based on RGs; they made it easy for me to maintain and shorten my code.

> 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.

Good luck !
Greetings, Jan Received on Mon Mar 08 2004 - 09:54:01 CET