Field value when used as script parameter vs. inside script (onModify, onObjectSave)

[Justin Close]

Can someone help clarify for me the different behavior on two different references to a field's value?

Looking at these 3 script triggers (and when they fire relative to the event):

OnObjectModify        After
OnObjectValidate      Before
OnObjectSave          After

Test case:  
    * Create an edit box layout object, pointing at a text field in a table (TableA::Field1).  
    * Create a script that reads the value of the field in two different ways:  
        Set Variable [ $inside ;  value = TableA::Field1 ]
        Set Variable [ $param ;  value = get(ScriptParameter) ]
    * Compare (in your preferred way) the two variables to see if they are the same.
    * Create a script trigger on the edit box layout object, that uses the field as a parameter:  
        Script Parameter = TableA::Field1

    *  Run the script trigger on each of the three different triggers mentioned:  modify, validate, save
    
Question to answer:  are the two variables the same?

Answers:

OnObjectModify      No
OnObjectValidate    Yes
OnObjectSave        Yes

I think that I can understand what is happening with 'Save':  the triggered-script fires after the event (the saving) so the trigger parameter reads the saved value of the field as does the internal reading of the field.

But Modify:  it also fires 'after' the event (i.e. the field has been 'modified' but not 'saved/committed' yet) but then why does the trigger parameter read the pre-modification value of the field, but inside the script it gets the post-modification value?

And I threw Validate in there just as another possible double check.  I actually thought that it would behave the same as Modify, since it was firing before the event (i.e I would think that means before it saves/commits it).  In reality it shows the field's value to be the post-edit value.

Thanks,
J

[comment]

But Modify:  it also fires 'after' the event (i.e. the field has been 'modified' but not 'saved/committed' yet) but then why does the trigger parameter read the pre-modification value of the field, but inside the script it gets the post-modification value?

 

First, instead of asking why, you should be grateful that this is how it behaves - since this can be an incredibly useful feature.

 

Now, I am guessing that although the script is performed after the modification took place, it is queued as soon as attempt is made to modify the field - and that is also when the script parameter is evaluated.

 

 

Note also that save ≠ commit.

[Wim Decorte]

I'm not entirely clear on what you are testing for.. especially this part:

* Create a script that reads the value of the field in two different ways:  
        Set Variable [ $inside ;  value = TableA::Field1 ]
        Set Variable [ $param ;  value = get(ScriptParameter) ]

 

it sounds like you are using a script that does the above on all of the events that you mention.  That doesn't seem like a good test.  Why don't you explain what you want to test first and then tell us what your expectations are?

[Justin Close]

@Comment:  Yes, I have used it before to good effect at least once.  It is a great way of checking before and after values of a field to see if it has changed.

 

I was hoping to do that only once for the entire field, though, instead of at every modification.  I was digging around at this because of our audit logging system.  It uses two triggers (one to record 'before' values, or the value on field entry; the other to get 'post' values and compare to the before value) and I was hoping to narrow that down to one trigger.  But, since the two values when used on the 'save' trigger are the same, that won't help.  The 'modify' trigger was the only place where one value showed the contents before any changes were made, and the other showed the value of the field after changes were made.

[LaRetta]

Yes, I use OnObjectModify so I only need one script to do both ... the script parameter uses:  Get ( ActiveFieldContents)  and then checks it against the value from within the script which will be after the change is made.

[Justin Close]

But then what are you actually logging?  If someone is typing into a field (e.g. changing the name of something), I would only like to log the fact that the field was previously "Bob" but afterward was "Fred".  Seems like, if I used onObjectModify, I would get log entries for "was 'Bob' now is 'F'", "was 'F' now is 'Fr'","was 'Fr' now is 'Fre'","was 'Fre' now is 'Fred'".  I.e. each time they modify it via keystroke it is logging the event (because they are different).

 

Would work OK if they are just pasting something in, or the value is controlled by a pick list; but for free edit text/number fields?  Can you enlighten me some more on your technique? 

 

Thanks,

J

[LaRetta]

I was only confirming what you said and giving example of way to gather before/after values.

 

 The 'modify' trigger was the only place where one value showed the contents before any changes were made, and the other showed the value of the field after changes were made.

 

But yes, my example only works for value lists.

[Justin Close]

Darn, was hoping you had a secret. 

[LaRetta]

LOL, I do the same thing. :-)