Are there any reasons, benefits, issues, etc with using hidden editable fields? I am referring to the hidden all the time flag fields usually put at the top of any given form. Any benefit-or-drawback to leaving them editable vs computed?
I’m currently editing an old database and I’ve noticed several fields that are editable but always hidden at the top of the form! I’m a stickler so when I asked if I could change it to computed to be consistent, the lead designer wanted to know if I could provide any reason as to why hidden fields should not be editable. And rightfully so, if it doesn’t hurt ANYTHING then it really isn’t a problem… but it just sounds contradictory to me, why have a hidden field that’s editable?
Subject: Courious question with hidden fields…
Because hidden editable fields behave differently from computed fields. They might use input translation fields etc. Whereas a computed field evaluates every open/save/refresh.
You would need to look at the formulae attached to the fields, one by one, to determine what they do.
Sion
Subject: RE: Courious question with hidden fields…
OK cool, so its not bad practice to use hidden editable fields? Good to know, thanks.
Subject: RE: Courious question with hidden fields…
Jeremy,
From a usability perspective, these fields usually serve as flags for the developer. Frequently they are populated by code that doesn’t care whether the field exists on the form, but the existence of the field serves as a marker for the developer. Often people will put remarks there, as well.
From a performance perspective, the fields on the form are a minor irritant. If they’re computed, then more so.
regards,
raphael