Imagine a Computed For Display (CFD) field that showed the result of @Now on a web page. Now imagine you submit the page and have the Web Query Save agent print back to the browser the value from this field. You might expect to see the same date/time value that had been displayed on the page. in fact you'd see the updated value of @Now, instead of @WhenIOpenedThisDocument. This is because computed fields get re-computed, once the form is submitted. Sometimes this isn't the desired behaviour and I've got a quick tip that might help.

Instead of using a computed field use a hidden editable field. Make the default value the same as you would any normal computed value. When you create the document from new this value is in effect computed for display. But normal editable fields never re-compute the value. To force it to re-compute each time we need to remove the field from the document each time it saves. This is easily done with the following line at the end of the document's WebQuerySave agent:

Call webDocument.RemoveItem("DocOpened")

So, it's just like a CFD field, in that it never actually saves with the document. Next time the document opens Domino gives it an updated value. Et voila!

But wait - there's one little gotcha involved. When I said the editable field was hidden I meant it was type="hidden" rather than actually being hidden from the browser. If you use Hide Whens the field is given its value at the time it's submitted. By having the browser send the field value to the server we can explicitly tell it exactly what value to use.

Where would this be useful? Well, I've used it in a solution to yesterday's scenario. When I open a document I want to log the time it was last modified. When it's submitted we can check this value with the one held in the back-end document. If they are different, there's a problem we need to deal with. I tried using the .LastModified property but found that didn't work. Instead I add a fake computed field, as described here, with a default value of @Modified.

The only drawback to this @Modified method is that it's only accurate to withing one second. There's an ever so small chance that two users could edit the document and these values still appear the same, but I can't get my head round the scenario required, so I can live with the risk. You can of course check more than simply this date. Maybe check the date and the name of the editor or the document's workflow status.

Expect an article talking about this. There's an interesting solution to a common problem in here somewhere. I just need to make the solution a little cleaner.