It’s not Thursday I know, but what the hell.
OK, this is one which I am guessing that I should have known but I am convinced that Domino used to work in a different way. What’s the situation?
Well, we have a document which is edited on the web. The document has a field on it called “MyField”, the form which is used to display the document on the web has a computed for display field with the same name. We are finding that when the document is saved, that “MyField” is being removed from the document.
This seems entirely correct if looked at in isolation, computed for display fields are not saved. But the reason I am posting this (and am entirely expecting to get abuse for being such a dumb-ass) is that I am convinced that in previous versions (I am thinking in the R5.x timeframe) that the field would not be removed from the document, instead whatever was stored in the field would be used by the computed for display field regardless of the formula in the field on the form.
So am I just remembering incorrectly or has the way that Domino works changed at some point in the last few years?
It’s not a big issue, we just changed how the form was working, just a little unexpected.
Technorati Tags: Show-N-Tell Thursday
Matt White 
How can you have 2 fields on the same form with the exact same name? Notes is not going to allow that even is one of the fields is a Computed for Display field. The only way I can think of it occuring is if they are on 2 different subforms. In that case, the behaviour you observed is absolutely correct. What I think you are trying to accomplish is to have a field defined via passthu HTML and stored in the document, in which case you will need a hidden field with the same name on the form.
Sean—
LikeLike
The field only exists once on the form (as a CFD), but a value has been populated onto the document by an agent. My query is why the CFD field on the form should remove the field on the document when the document is saved through the web.
Matt
LikeLike
Matt, I think you are exactly right, except I think it happened either going from 4.5x to 5.x or somewhere in the 5.x codestream. I remember having similar problems in our applications. We ended up changing the names of the CFD fields.
LikeLike
Could it be a web-related issue? If “Generate HTML for all fields” isn’t on, a web edit-save cycle can blow away fields.
LikeLike
I also remember the rule that existing stored values on the document will trump whatever formula happens to be the CFD at present. I often make computed fields into CFDs on applications I inherit (where it makes sense), and always run a cleanup agent to remove the old stored values. I guess I should experiment to see if that is in fact still necessary.
On a related note, I remember one reason that older applications used Computed fields where you’d think a CFD would work just fine. If you have formulas in fieldA dependent on a the value of a (hidden) CFD fieldB, it used to be that the value of fieldB would not be available for the computation. You HAD to make fieldB computed for the dependent formula in fieldA to work. Not only that, but I used to have to write cleanup routines that would remove fieldB and its brethren when the doc was closed, in order for those fields to mimic CFD behavior (i.e. always computing afresh when document is opened). I’ve noticed in more recent releases that the CFD approach works fine without all the kludginess…I think it was fixed in 5, but I didn’t “trust it” so continued the old approach for a while. I’m comfortable that 6 works.
LikeLike