View member feedback to this tip.
If you really to ensure fields have changed, and in an easy way, don't use computed for display fields -- just use LotusScript.
Declare a Public list as variant, then fill the list with keys as the field names you want to have checked for changes. Call a sub on the post open (only when the document is in edit mode); this fills the list with the values for each entry. You can even check if the field exists or not.
Then, in the query close event, run a second sub that compares the values of the list entries with the values you now have on the document, and take appropriate action.
You don't need to add computed fields if the required field checks change. You only add one entry to the list with fields and that's it.
Declarations:
dim aFieldsToCheck list as Variant
PostOpen:
Forall field in aFieldsToCheck
If source.document.hasitem
( listtag( field ) ) then
aFieldsToCheck =
source.document.getitemvalue( listtag( field ) )
end if
end forall
QuerySave:
Forall field in aFieldsToCheck
if HasFieldChanged
( source.document, listtag( field ) ) then
' do your required action
end if
end forall
Globals:
function HasFieldChanged( doc as
NotesDocument, strFieldName as String)
HasFieldChanged = False
' per default no change assumed
' this is only one variant of checking
' if you have multi value fields you need
a more advanced checking mechanism to
cross check all values (i.e. is the order
important etc.)
if doc.GetitemValue( strField )( 0 )
<> aFieldsToCheck( strField )( 0 ) then
HasFieldChanged = true
end if
end function
MEMBER FEEDBACK TO THIS TIP
The overall idea of this tip is good, but there are some problems.
Suppose a field is not present when the document is loaded, but is present when the document is saved. This can very easily occur if the form design has been modified since the document was last edited, and a field added. This line: if doc.GetitemValue( strField )( 0 ) <> aFieldsToCheck( strField )( 0 ) will then cause an error ("List item does not exist") because strField is not a member of the list.
If the field has a text value when the document is loaded, and has a numeric or date value when the document is saved, the same line will cause an error ("Type mismatch"). This can happen if the form design has been edited since the last time the document was edited, or if the field's input translation formula may return values of different types.
The same line can cause an error if the field contains an "error" value when the document is opened or when it's saved. The error in this case would be "Variant does not contain a container," because an error value is not returned as an array.
As noted in the tip, it doesn't handle multivalue fields. It could easily be modified to do so.
It should also be noted that this tip doesn't work with rich text fields. In addition, it doesn't technically track field changes. It actually just detects field changes as the document is being saved. Tracking would require that the information also be written somewhere for future reference.
—Andre Guirard
Do you have comments on this tip? Let us know.
This tip was submitted to the SearchDomino.com tip exchange by member Michael Zischeck. Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
