• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1228
  • Last Modified:

Won't display new value of field changed by Lotus Script

After changing a field property from say 8 to 6 and displaying the document, the old 8 still shows.  When I right click and check the properties it does say 6.
Trying everything to update and refresh the document and nothing works.  I keep viewing the page and it shows 8.
  I was told to use a "compute for display" field, but I don't know how to make a field of this type.
I don't want to have to use events as this is supposed to be able to run straight off as an agent and we have no idea how many fields would be needed to setup with events, but too many to want to do events.
  When I edit the document it does show the 6 but then it vanishes two seconds later.
  I see now that the document only truely saves when it is in edit mode, yet I need to have the document display 6 once I change it from lotus script, any ideas?

1 Solution
Check your QuerySave for possible retainment of old values for that field.

If you think there is no other event/script is resetting then values, then remove the desktop icon of the database and then re-add and open

Also check your rights to the database. For example, if you have Author access to the database and that field has the option "Must have at least Editor access to use" checked, then Notes will allow you to edit the field, but when you save the document, your edits will not be saved. If this is the case and you attempt to use an agent to set the field value, it will also not work.

However, in this case, since you say that you verified that the value has changed successfully in the back end document (as viewed through the document properties), then it is more likely a display issue. Make sure you are looking at the right field (sometimes, designers will use two fields for one purpose, one editable, and one computed). Also check that the field value itself is not something like NumberField + 2, which would obviously make it display 2 more than what is stored in it.


Has the computed for display field been editable/computed/computed when composed in the past? In that case the field is there in/on the document. Computed for display fields are not stored and unfortunately stored values are always shown instead of the cfd-computation!
field "a" (ed) = "1"
field "b" (computed, inherits value from field "a") = "1"

edit field a into "2":
[a] = "2"
[b] = "2"

b changes to cfd (still inheriting from a), a is edited into "3":
[a] = "3"
[b] = "2"

If this is/was the case, you could either delete the old doc's an create/test new ones, or specifically remove the (cfd) field from the document(s) using an agent containing:
field <name>:=@Unavailable
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

It sounds as if you are using an agent to modify the document at the back-end, and there are some form calcualtions that modify anciliary fields.  Agents do not fire form calculations, so the anciliary fields do not change.

For a formula agent, try using @Command([ToolsRefreshSelectedDocs]) as a spost-processomg step to update the formulas.  If using a LotusScript agent, you can use NotesDocument.computeWithForm.

I never use these features.  They are slow, and have had past bugs.  I would much rather make sure my code updates any extra fields.  But if you want, the @Command or the ComputeWithForm method, will do what you need.
Check and make sure you don't have an Input Translation formula running for the field.
volnAuthor Commented:
This is very helpful.
I talked to the Marin tech support programmer and he said this is the way Lotus Notes does it.  That I should create a new compute for display field and set the value of this field.

  Creating a new field does let me show the value from the field that should show it!  So the field I make shows 6 or 7 or 8, whatever I set the hours to, but the original field that holds this value still shows 0.
  I've looked at the code for the events and added code like the posters here said and none of the LS code or formulas has forced the form/view to recalculate/update and show the correct value.

  Is there a way to hide this original field and then just add my new field in that can actually show this value?  That would work for me.

I think we need to start over again here.  Notes isn't really that complicated -- though you can create overly comlicated applications in it -- and changing field values is very basic.  The computed for display business is probably inappropriate, because your agent should be modifying the document so that results are as if the user had entered the changed value... i.e., any calculated changes also need to take effect.

Go to the form design.  Put a red X next to the field you THINK you are changing.  Note the exact field name.  Save the form.  (Also, make sure the field is either EDUTABLE or COMPUTED or COMPUTED-WHEN-COMPOSED, but not COMPUTED-FOR-DISPLAY.  Open properties for the field, it is the drop down list about one-quarter way down on the right side.)

Open an unchanged document (i.e., that your agent did not touch yet).  Make sure the X is next to the unchanged field value.  Close the document, and look at it in the view.  Open the document properties while in the view.  Check the field's value.  If you see no X at all, then the field was hidden, and the display field

Now, go back to the designer, and open the agent.  Make sure the field name is the same there as well.

Also, if this is a script agent, make sure you are getting the correct document, and that you are saving it.  You can confirm the document by doing a PRINT DOC.NOTEID (assuming your document object variable is called DOC).  Compare the printed value to the Note ID on the document properties (click on the last tab -- the beanie -- and look at the bottom value, which is prefixed by "NT00.." -- the leading NT and zeroes don't matter).  To save the document, use DOC.SAVE TRUE , TRUE after changing the field value.

OK, now run the agent against the document you checked before.  Check the field properties.  See if the value has changed.  Open the document.  Has the value next to the X changed?  I would bet it has changed.  If it hasn't, then perhaps there is a script in the form that resets the value of the field when it is opened -- look at the forms QueryOpen event and PostOpen event.
volnAuthor Commented:
 Yes!  That was it, they had done something to completely fake me out.  They had tons of code in PostOpen, but the key was in another script.  The variable I used was for tempory use, display only.  The real variable was named something else.  Why they did this I have no idea.
  How would I have known the variable in the field name wasn't the true variable!
  Thanks for all the help from everyone.

If it hasn't, then perhaps there is a script in the form that resets the value of the field when it is opened -- look at the forms QueryOpen event and PostOpen event.

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now