1 Reply Latest reply on Feb 13, 2014 3:55 PM by Stephen Huston

    FMP/A v13 - Concatenated Merge Text or Calculated Merge Text?


      Hi All,


      Does anyone yet have an answer for the following query, with explanations?


      I'm re-designing a solution from the ground up, to be as FMP/A v13 friendly as possible. This of course includes using the style sheets, plus building a custom theme. For the main data entry layouts, I want to use popovers (with or without slide panels, depending on context).


      This is a way to hide the detailed field entry, allowing for a summary to be displayed on the main layout. The final result is more visual spaciousness on the main layout, plus a more succinct view of the pertinent data details.


      Query: What is the best way to display that summary information? I think merge text is more appropriate than fields however is there any performance or long term maintenance reason to choose between the following two options?

      1. Concatenated and formatted merge fields on the main layout.

      2. A calculated field for the concatenated and formatted data.


      The calculated field option is necessary (for 'best' presentation) in some cases due to the nature of the underlying data but it is optional in others. Should I just stick with conventional merge fields, or build the calc? My feeling is that the calc is the way to go because the management is a bit more centralised (ie a bunch of calcs, clustered together) and less likelihood of 'style drift', but I don't know if this is undesirable for long term performance or whatever.


      Any thoughts on 'best practice long term design strategy'?


      All the best,


        • 1. Re: FMP/A v13 - Concatenated Merge Text or Calculated Merge Text?
          Stephen Huston

          That depends on a lot of stuff.

          No, really...


          I am unclear why you believe adding a calculation field (or several) to the table itself is best for presentation, but, in those cases, it might be worth it. I tend to avoid adding data fields of all kinds -- but especially unstored calcs -- to a table unless they are necessary.


          I also have finer control over the appearance of merged text on a layout than with calc fields. The various pieces of merged text in a block can be formatted separately if desired, but creating a formatted result in a calc can be a ton of work, if it works at all.


          Looking down the road, I would not want to build a complex solution which relied on merging via calc fields, and then have to go in a modify "some" of the places it appears, while the users may prefer some places not to be changed. Text blocks allow that at the layout level. On the other hand, if you are confident that changes will be an all-or-nothing modification to all instances, then modifying a single calc result would be faster for updating a bunch of layouts.