3 Replies Latest reply on Feb 18, 2016 10:51 PM by mardikennedy

    FMP/A 14 - Style Loss/ Inconsistencies

    mardikennedy

      Has anyone else had style definitions 'drop out' over time?  (Once only for me so far, but dreading that it might become more common.)

       

      Background:  solution created in FMPA 13, with custom theme.  Some styles are Helvetica based; others are Verdana based.

       

      Description:  one style is specifically Verdana 16 - been used, probably unchanged, for over 12 months.  Currently only applied to one merge field, on various layouts.  Yesterday, it suddenly started displaying as Helvetica 14-ish - ***but only in Browse mode***.  It continues to display as Verdana 16 in Layout mode.

       

      It's not font corruption at OS level - Verdana 16 displays fine in other apps.  It's not font corruption at the FMP level - Verdana 16 displays in a brand new solution.  It is specific to this solution.  Note:  the other verdana based styles in this custom theme continue to display verdana correctly.

       

      I have tried importing the theme from a backup file but the 'helvetica in Browse mode' problem persists.

       

      It is very disconcerting when a defined style simply 'changes'.  There is no conditional formatting involved.  No layout triggers, or script triggers.

       

      Sound familiar to anyone?

       

      Obviously, my preferred alternative is to have the correct display in Browse mode.  I am continuing to experiment with changing the definition to see if a good enough alternative will 'stick' but this all takes time, and this is something that I would have preferred to have been spending on productive work.

       

      Message was edited by: Mardi Kennedy

        • 1. Re: FMP/A 14 - Style Loss/ Inconsistencies
          mardikennedy

          Granular details.  It turns out that the style of a merge field will prevail over a 'styled' field (from a related table), BUT NOT over the customised content of that field.

           

          In normal development/ layout mode, you can easily see if a field has 'custom' rather than purely styled content, via the red triangles.  IF, HOWEVER, the field's content has been changed at the user end, via Formats/ Fonts, there is NO indicator to show that the content is custom.  Also, when you go into layout mode, there is no indicator that this content is now custom.

           

          Thus, if the source field has been fiddled, i.e. customised, then the style of the merge field in the related table WILL NOT prevail over the attributes of the source.  Conversely, if the source field is styled (but not customised), then the style of the merge field WILL prevail over the source's attributes.

           

          Personally, I think this is a limitation of the generated CSS - it would be good if it was easier to track down the details.  Example: user applies fonts that look identical to normal styling so that now the field behaves as a customised field rather than a styled field.

          • 2. Re: FMP/A 14 - Style Loss/ Inconsistencies
            Stephen Huston

            I use custom menus to change the Paste command to Paste plain text (without styles), and remove many of the Format menu options to keep users from embedding formats in the actual data. Too many things can go wrong in reporting when data contains its own format.

            • 3. Re: FMP/A 14 - Style Loss/ Inconsistencies
              mardikennedy

              That's a good idea.

               

              Given the realisation of the extent of style behaviour quirks, not just a 'good idea', but probably absolutely essential :-)  To clean things up, not only did I need to replace the source field itself, I also needed to remove the data and then replace it.  In this case it was straightforward because it happened to be a 'setting', but in another data context, it would have been a real pain.