Does anyone have any info around using computed text vs computed for display fields?
Both essentially offer the same solution, displaying a value on the form while reading or editing.
My initial thought is that because Computed for Display fields take up memory space of the NotesUIDocument and NotesDocument, they would not be the choice for something that just needs to be displayed to the user with not need to access it’s value.
–Rob
Subject: Performance: Computed Text vs Computed for Display Field
Computed text can be used on pages and cannot find their way into the database field list, but there’s is a really small limit on the amount of text (less than 2K characters) and the result cannot be programmatically referenced elsewhere. Computed-for-display fields can be referenced, can have a much larger output and can be multivalue, but will count as fields for purposes of the UNK table, view/search field selections, etc., without actually being available for use. Those are the items you should be considering rather than ultimate performance – it is unlikely that a form will be big enough to make memory a problem on anything that’s not hopelessly obsolete.
Subject: RE: Performance: Computed Text vs Computed for Display Field
I had a 32K limit with a computed for display. When I use Computed text instead, it works and the string I compute is in my web page.So I do not think that 2K is the limit for computed text.
Subject: RE: Performance: Computed Text vs Computed for Display Field
“will count as fields for purposes of the UNK table”
Actually, I think if you set the “do not add field names to field index” option on the form, it will only add the saved fields to the UNK table.