post-query & when-validate-item triggers
Gert Ormel
A common situation in Forms is to have a post-query trigger populate the
non-base fields in a base-block. A when-validate-item trigger on the
non-base fields ensures that users can not input rubbish and populates the
(usually) hidden base-fields (e.g. ID fields) by calling a function or
procedure.
A problem with this scenario is that after query, the :system.record_status
is always set to ‘CHANGED’, as the validation triggers fire, overwriting the
hidden ID fields.
Adding the condition :system.record_status <> ‘QUERY’ to the trigger-text of
the when-validation-item triggers is not appropriate, since this would imply
that after query, user input is not validated and the hidden fields will not
become populated either.
Using a pre- and post-item trigger on the non-base fields in stead of a
when-validation-item works well, except when the user changes the value in
the non-base field, realises that the change was wrong and sets the value in
the field to what it was originally. In this situation, when s(he) wants to
exit the screen, Forms issues the alert ‘Do you want to commit changes? This
is slightly confusing, as the user thinks that there haven’t been made any
changes at all.
Any suggestions for a ‘clean’ solution are appreciated.
Gert
Wim Jans
Set_Record_Status(Name_In('system.trigger_record'),
Name_In('system.trigger_block'), STATUS, QUERY_STATUS);
Wim
Gert Ormel heeft geschreven in bericht <71k0mn$7s3$1...@aquila.mdx.ac.uk>...
Joe Brown
trigger:
set_record_property(:system.trigger_record, :system.current_block,
STATUS, QUERY_STATUS);
T o prevent forms from thinking that the user has changed the data in
the block.
This technique has served me well with Forms 5.0. I think it will work
with 4.5 also..
In article <71k0mn$7s3$1...@aquila.mdx.ac.uk>,
Gert Ormel <g.o...@mdx.ac.uk> wrote:
>Hello all,
>
>A common situation in Forms is to have a post-query trigger populate the
>non-base fields in a base-block. A when-validate-item trigger on the
>non-base fields ensures that users can not input rubbish and populates the
>(usually) hidden base-fields (e.g. ID fields) by calling a function or
>procedure.
>A problem with this scenario is that after query, the :system.record_status
>is always set to ‘CHANGED’, as the validation triggers fire, overwriting the
>hidden ID fields.
>Adding the condition :system.record_status <> ‘QUERY’ to the trigger-text of
>the when-validation-item triggers is not appropriate, since this would imply
>that after query, user input is not validated and the hidden fields will not
>become populated either.
>Using a pre- and post-item trigger on the non-base fields in stead of a
>when-validation-item works well, except when the user changes the value in
>the non-base field, realises that the change was wrong and sets the value in
>the field to what it was originally. In this situation, when s(he) wants to
>exit the screen, Forms issues the alert ‘Do you want to commit changes? This
>is slightly confusing, as the user thinks that there haven’t been made any
>changes at all.
>Any suggestions for a ‘clean’ solution are appreciated.
>
>Gert
>
>
>
--
(: Joe Brown :) j...@apache.dtcc.edu
I believe Wine is going to be great if it ever gets finished. . .
I believe Linux _is_ great even though it's not finished! ! !
I believe you have my address. :-)
GLucas4189
It is not the fact that nbt items are changed which causes a base table update,
it is the fact that there may be LOVS VALIDATION on a nbt, which gets reflected
back to a base table item mapped within the LOVS iteself. This occurs of course
when the base table item is already populated from the query and is then marked
as changed because the LOVS attached to the nbt has retrieved a second value in
to the base table item.
In addition validation triggers like WHEN-VALIDATE-ITEM, that are written
against nbt items will fire. If the validation trigger populates a base table
item value in another block, as I have seen with some code (admittedly dodgy !
), then it will fire a base table update in that other block, which means that
the SET_RECORD_STATUS - clause, in the previous post is not necessarily
sufficient. The solution is to introduce as well as this a flag which is set at
the beginning of the POST-QUERY trigger, and unset at the end. For example :-
POST-QUERY
:blk.hi_query_flag := 'Y';
code etc...
:blk.hi_query_flag := null;
On your corresponding WHEN-VALIDATE-ITEM triggers, you would the code as
follows :
BEGIN
if :blk.hi_query_flag is null then
:blk2.value := :blk1.value;
end if;
END;
Don't recommend these kind of assignments anyway...but after debugging a few,
this seems to be a solution...
In addition ensure that LOVS_VALIDATION is set to false in your field
properties, or set to false by the use of the
SET_ITEM_PROPERTY(:system.cursor_field, LOVS_VALIDATION, PROPERTY_FALSE) etc...
You could code this automatically by writing an ON-FETCH trigger which would
loop around all records in the block and perform the
SET_ITEM_PROPERTY(:system.cursor_field, LOVS_VALIDATION, PROPERTY_FALSE) etc...
and then the FETCH_RECORDS built in..
If you wanted to automatically switch on LOVS_VALIDATION in normal processing
you could write a form level PRE_TEXT-ITEM trigger :-
PRE-TEXT-ITEM
if field_lovs ( some function to find it if is a LOVS field )
set_item_property(:system.cursor_item, LOVS_VALIDATION, PROPERTY_TRUE)
end if;
and then switch it off a POST-TEXT-ITEM trigger :-
BEGIN
if field _lovs then
set_item_property(:system.cursor_item, LOVS_VALIDATION, PROPERTY_FALSE)
end if;
Be careful with internal navigation also, because even if the user does not
navigate to a field, but you do programmatically, the LOVS_VALIDATION settings
will fire due to PRE-TEXT-ITEM above. In this case, for internal navigation, is
it is advisible to set the LOVS properties of the fields to null, to ensure
that it cannot fire, and then reset it afterwards, after your internal
navigation.
Hope this helps...
Graham
Actually, thinking about it.. you could write a form level POST-QUERY trigger,
which would have
set_record_property(:system.cursor_block,RECORD_STATUS, QUERY) etc..
But then, you would have to ensure that every block has the execution
hirerarchy set to 'before'... so that the form level POST-QUERY trigger would
fire.
But you would still need to watch out for those LOVS_VALIDATION settings for
internal navigation...