Input Enabled formula
While we're on Computed for Display, there's a recent (well, since 6.5) feature of editable fields called the Input Enabled formula. The Notes 6.5 help looks like it was re-edited in a hurry and not properly proofread afterwards. It says that there are three Notes field formulas, and then describes four - the traditional Default Value, Translation, Validation and the then new Input Enabled, and gets it wrong about what the formula should return.

Designer 8 help is at least more accurate, though actually less clear about what this formula does. So, briefly: The point of an input enabled formula is to allow you to determine if a field may be edited or not. Use a formula that results with one of @False or @True. This is pretty much as you would use a hide-when formula, except in reverse: Input Enabled @True means that the field is to be editable by this user, while an @True hide-when result hides the field.

These formulas allow you to bypass the old trick of having two fields, one editable and one Computed for Display using the value of the editable field, then displaying one or the other depending on whether the current user is able to edit the field. Note also that Input Enabled formulas originally - in 6.5 - required that the field was of Native OS type, but that restriction was removed in Notes 7 and they work with conventionally displayed Notes fields too.

Notes fields aren't strictly typed
Another not uncommon trap with fields stems from the fact that Notes fields aren't strictly typed. When you create a field with LotusScript or formula language, the field type is derived from the value that you assign. As the help for NotesDocument.ReplaceItemValue says: "The data type of the item depends upon the data type of the value, and does not need to match the data type of the old item." and it goes on to explain how it is set.

Notes doesn't care whether the same field on different documents is the same type either, because Notes doesn't have a database schema. You can read about the lack of a schema in Notes in an article I wrote a few years ago, "Notes is not a relational database".

This ability for Notes to store whatever values it has in a field without any reference to type is part of what makes Notes what it is. But when a field is displayed in a form, things do get a little more strict. Notes is happy enough to display any value in any field as the form is displayed, and still happy to do so when the form is in edit mode, but when it comes to save time, then the field value must match the field type as defined on the form, or the document won't save.

There's no silver bullet to this one, either - to get the document to save via its form on the front-end, the field values and types have to match. That goes for an error-free Compute with Form operation, too, by the way. So this is a good reason not to have any hidden editable fields on a form. Should the values get damaged, the document won't then save, and because the fields aren't editable, the user can't correct them, and it will all be your fault - even if you'd had nothing to do with it.