Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.misc -> Re: Forms4.5 problem
Alan Campbell wrote:
>
> Can anyone advise me on how to get around a problem that I have encountered in
> Oracle forms 4.5.
>
> I have a block that is based on a base table, which displays the contents of
> each record and allows the user to modify the details.
>
> One of the fields (base table) is a status which is held as a character value
> ('00'-'07'), which has an associated meaning.
> eg.
> '00' = Registered.
> '07' = Closed.
>
> I want the users to be able to modify this value without having to know what
> each value means.
>
> What I have done is to overlay the status field with another field that is not
> based on a base table item (this field will contain the translation of the
> status), and created a LOV, that displays the translation of the status, the LOV
> also updates the contents of the base table field as well as the new field when
> the user selects a new status.
> This works ok, but the new field is only ever populated when the user selects
> something from the LOV. What I wanted was for the new field to display the
> status when the form starts, so I created a WHEN-NEW-FORM-INSTANCE trigger and
> placed some code in it to populate the new field, based on the status value from
> the underlying table.
> The problem is that the user is always prompted to save any changes to the form
> when they exit (COMMIT_FORM), when they have not made any changes. I am
> assuming this is because I have populated the new field on startup which has
> caused the form status to be set to changed.
>
> Is there a way around this problem ?
First of all: Why don't you use a List Box?
2nd: try the following:
Every time you populate the LOV (i assume it's in a trigger) test the
corresponding
field variable and check if it changes, e.g.
IF :block.status != newstatus THEN
:block.status := newstatus;
END IF;
Therefore the changes are always done if there are changes.
3rd: Do you not distinguish the following cases:
The 1. function does not change the database fields so therefore it's save to call them from WHEN-NEW-FORM-INSTANCE (i would prefer to call it from POST-QUERY).
The 2. function changes this status, and should be called in every field that affects the status by the ON-VALIDATE-ITEM trigger. In this function it's good when you check the status as mentioned in 2nd. This function has also be called after showing your LOV...
Hope this helps
-- ---------------------------------------------------------- IMSoft - Dipl.-Ing. Michael Karg Graf Starhemberggasse 32/2/3 1040 Wien Austria ---------------------------------------------------------- e-mail : karg_at_uranus.tuwien.ac.at michael.karg_at_bigfoot.com +436641015732_at_text.mobilkom.at Tel & Fax: ++43/1/5056190 A1 : ++43/664/1015732 WWW : http://uranus.tuwien.ac.at/~karg/imsoft.html http://titania.tuwien.ac.at/~karg/imsoft.htmlReceived on Wed Apr 23 1997 - 00:00:00 CDT
![]() |
![]() |