Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Forms4.5 problem

Re: Forms4.5 problem

From: Karg Michael <karg_at_uranus.tuwien.ac.at>
Date: 1997/04/23
Message-ID: <335DD0B0.836@uranus.tuwien.ac.at>#1/1

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:

  1. QUERY from the database: convert from the Database field (status) to some other things (e.g. status indicators that the user see and probably can change)
  2. USER enters a value in such fields

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.html
Received on Wed Apr 23 1997 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US