AnsweredAssumed Answered

Theme + Style update: Style with same name import bugs

Question asked by mrwatson-gbs on Feb 1, 2016
Latest reply on Jun 12, 2018 by mrwatson-gbs

Product and version (FMPA 14.0.4 - but maybe all fm14.0.*)

OS and version (Mac - but probably irrelevant)



In fm13 themes and styles were updated based ONLY on their internal ID. In fm14.0.1 this was improved, so that BOTH style internal ID AND the (visible) style name are used for matching purposes. (=> THANK YOU FMI!)


However, after testing I have discovered that there are two remaining bugs which occur in the following cases:


Bug 1. Matching name, different internalID => Strange 'Layout Cacheing Problem'


If a style matches by name but not by ID (and matches by type), the following STRANGE situation occurs:


Bildschirmfoto 2016-02-01 um 13.12.15.png


Field D should look blue, but it doesn’t! It looks white!


It seems like the import has worked to a major extent:


  • The theme seems to have been correctly imported. (Verifiable by looking at the theme fmxmlsnippet)
  • The style has been updated, and the internalID has been changed in the style ‘red' (Verifiableby looking at the theme fmxmlsnippet)
  • The layout object has been changed to have the internal ID of the imported style (Verifiableby looking at the object fmxmlsnippet)
  • When the object is selected the blue DOES appear correctly in the fill panel (top-right) and in the inspector!


The field appears stubbornly white. (I didn’t check, maybe it has the default appearance?)


The problem seems to be anchored in each layout - in some kind of “local cacheing” of the appearance, and not in the theme itself.


To help try and locate the source of the problem, I tested various actions and made the following discoveries:


  • Changing + saving the layout corrects the problem - however, only for the saved layout  all other layouts continue to suffer until treated in the same manner.
  • Changing and saving the theme only corrects the problem only for the saved layout, but does not fix all layouts.


The following actions did not change anything at all:


  • Changing from layout mode to browse mode and back does NOT change the appearance.
  • Changing between layouts which contain such objects does NOT change the appearance of the objects.
  • Indeed, changing to a second layout containing similar ‘red’ objects, they seem to all suffer the same problem.
  • Opening the Theme Management window and pressing OK does NOT change the appearance.
  • Closing the File and reopening the file does NOT change the appearance.


Some actions caused the blue appearance to return whilst in Layout mode, but EXITING THE LAYOUT WITHOUT SAVING caused the object to regain its whiteness again:


  • Duplicating the object clears the problem, and the appearance is corrected (field shows blue) immediately the choose field dialog appears
  • Opening the Theme Management window and then pressing [cancel] or OK SOMETIMES clears the problem and the appearance is corrected (field shows blue)



Bug 2. Matching name, different internalID, different style object type => “Deleted style is reset to default appearance"


If the style with a matching name is of a different object type, then the import is successful: the old style is deleted, and the new style is correctly imported. The ‘glitch’ is the objects which had the old style have not only their style name reset to default, but also their appearance. This is a special case of the STYLE IMPOSTOR - Appearance is reset when theme imported/overwritten problem,



How to replicate

These test files can be downloaded under the following link: fmWorkMate - Makes FileMaker Work - from

1. I created 6 test files in folder ‘Originals' - in order to check all possible combinations of matching style-name, style-internalID and style-object-type:


File A - the MASTER theme file, with Theme ‘ThemeA' and field style ‘red’ with a red background

File B - File, with imported ThemeA and unchanged field style ‘red’ (= Same style name + same internal ID)

File C - File, with imported ThemeA and style ‘red’ renamed to ‘rot’ (= Different name + same internal ID)

File D - File, with imported ThemeA and style 'red' deleted and then recreated (= Same name + different internal ID)

File E - File, with imported ThemeA and style ‘red’ deleted and TEXT style ‘red’ recreated (=  Same name + different internal ID + different type)

File F - has both styles of File C and File E (‘red’ renamed to ‘rot’ plus a new TEXT style ‘red’ (to see if internal ID or name has priority)


  • Each File has a layout based on ThemeA and a field with style ‘red'
  • except for File E that specifically had a label text styled ‘red’ instead of the field.
  • and of course the style in File C is called 'rot' instead of 'red'
  • Plus in File D the layout field and then the layout were duplicated in order to study the effects of Bug 1.


2. I copied the 5 Files to folder 'Theme Update in fm14.0.4’, then in this folder:


3. I opened File A and gave style ‘red’ the color blue, and saved style and theme.


4. I opened each of the files and reimported/updated the theme from File A, with the following results:


File B - Same name + same internal ID = OK

File C - Different name + same internal ID = OK = style name updated

File D - Same name + different internal ID = Bug 1

File E - Same name + different internal ID + different type = Bug 2

File F - style ‘red’ was deleted (i.e. Bug 2) and style ‘rot’ was updated + renamed to ‘red’ (-> internal ID has greater priority than name)


In the case of File D / Bug 1 I then repeatedly had to delete the file and re-copy the original and re-import the theme in order to see what actions affect the appearance.




Bug 1.: ‘Don’t hold it like that’ / None (At least, I cannot find an action that leads to a verifiably correct import + layout appearance).


Or in other words we must return to our fm13 methods of creating styles only in the “theme MASTER” file and import/update styles based on internalIID.


Bug 2.: ‘Don’t hold it like that’ / None / Go back to fm13 methodology.