I ran across a very annoying difference between display forms and regular forms as I upgraded a custom app.
In the old app, a diary field and a char field (with limit of 0) were displaying their contents in read only mode so the user could see past activity and ongoing dialogue on that ticket (pulled up from underlying sub forms for display). Now the new version tries to do the same but in a regular form. The problems two-fold... 1. A display-mode char field does not display it's conrents . it shows as a blank field unless you hit the expander box and read the contents in the popup. Fail. 2. An option-mode char field, all other options the same as above, displays it contents as expected. 3. A diary field also does not show the contents in the regular form and must be expanded. I ran controlled experiments on these fields side by side on both a display form and on a regular form where applicable. On a display form, both char and diary fields showed the contents. On a regular form, only an optional or required char field showed their contents without a expansion, not diary and not display-type char. No other option or attribute affected the comparisons. This meant a big ugly rewrite to a lot of filters that wrote to the old diary field to now accommodate the same functionality in a char field as it was the only option that worked as desired for the functionality at hand from a UX perspective.. Pain. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
