1 Reply Latest reply on Mar 14, 2014 2:19 PM by Michael Westendorf

    Custom Style, None Option for Fill and Line Attributes

    Michael Westendorf


      Custom Style, None Option for Fill and Line Attributes


      FileMaker Pro


      13 Advanced

      Operating system version

      Mac 10.9.2

      Description of the issue

      Saving a custom theme and overriding the default style does not respect the none option for the fill or line appearance.

      Steps to reproduce the problem

      1) Create a custom theme.
      2) Add 4 fields to your layout.
      3) Change the first field and save the changes as the new default style.
      4) Change the second field to have no background fill color and save it as a custom style.
      5) Change the third field to have a background color and save is as a custom style.
      6) Change the fourth field in anyway, make the font size 32 and set the fill to none. (local style)
      7) Now change the first field (Default) background color and save changes to current style.

      The same is true for line settings as well.

      Expected result

      Only fields with the default style applied should change background colors.

      Actual result

      All fields on the layout with a fill option of None are changed to the default, even the custom style that was saved.


      None that I am aware of at this time.


        • 1. Re: Custom Style, None Option for Fill and Line Attributes
          Michael Westendorf

               Ok. I will update my own post. 

               After creating the fields if you go back and set a fill then set it back to none and save the changes it will retain the fill option of none.

               I guess I just do not expect anything to change in a custom style after I have saved it. It appears FileMaker is only saving the css for the items I changed from the default. 

               This does make sense in a pure css world but since we can not view the detailed css per style; I think a better behavior is to copy the css entirely. This would ensure custom styles would not get updated unexpectedly. Otherwise giving us access to view the css would make it easier to see what will be changed when overriding the default. As it stands it is impossible to know which objects will be changed.