Thank you for your post.
If you changed the style after importing the Theme, the next time you import the same Theme, any new styles will be overwritten by the original styles. This would also apply to importing data. For example, if you import data, make changes in the second file, and then import the first file again updating the information, any new changes in the second file will be overwritten by the original information.
I am not sure the analogy to a data-import is helpful. Or maybe on the other hand, it is:
This error-report is not about styles that MATCH, it is about styles that DO NOT match. In step 4 above (oops the second step 4) I create A NEW style "This style will be removed" in file 2, that has NO MATCH in File 1.
Using the record-import analogy, to highlight the problem: It is as if the import records command would reset all records that have no match in the file being imported to have empty data.
Drawing (a more useful) analogy with copying + pasting layout objects:
When you COPY + PASTE a LAYOUT OBJECT into a NEW EMPTY FILE (which of course has no themes nor styles in it), the pasted object is NOT reset to look like a standard object, rather the style information is simply moved into the local CSS, so that the pasted object LOOKS exactly the same as the original object.
What I am arguing here, is that the theme-import behavior should be the same: instead of resetting the LOOKS, just move the style information into the local CSS.
It doesn't matter how much one argues about whether FileMaker, in its current implementation, should or shouldn't behave like this, I am simply (helpfully) reporting the fact, that FileMaker currently behaves in a way which
- is unexpected (to ALL users)
- makes a lot of work for the users to repair the "damage" (and it is perceived as "damage")
- makes managing themes almost impossible
- and thus devalues the whole theme functionality
In other words: I am not trying to bash FileMaker with a stick, I am trying to communicate to FileMaker as efficiently as possible, a bunch of problems with the current implementation of themes, so that WE (FileMaker Inc. + its fan club / developer community) can get a better product as quickly as possible.
Thank you for your help :)
Günther Business Solutions GmbH
Perhaps I'm having difficulty understanding the issue. Let me know where I'm misunderstanding.
In the first step #4, you create a new file (File 2), and import Theme "A".
In the second step #4, you add a new button into the current Theme "A", apply it's own "distinctive" style, and then you save the style and update the current Theme "A" to include that style.
In step #7, you reimport Theme A with all its styles into File 2. If I understand you correctly, you want the importing of the Theme to match up each style, update any matching styles, and not overwrite any new styles added to the Theme.
I have numbered the steps 4.1 and 4.2 to make them easier to refer to.
This post identifies a pitfall with a major drawback when a developer /development team make a small error in theme management, that is the error of creating a style in the wrong file (file 2) and accidentally overwriting it when the style is updated from the master themes file (file 1)
Step 4.2 thus becomes:
In #4.2, you add a new button into the current Theme "A" of file 2, apply it's own "distinctive" style, and then you save the style and the changes to the theme and update the current Theme "A" in file 2 by importing it from file 1
to include that style.
What I want is:
- I would like re-importing of themes to NOT reset the appearance of unknown styles to standard. <= This I consider a bug.
- I would like re-importing of themes to leave the appearance of new styles as they are. <= This I consider a minimal solution to the bug.
- I would LOVE re-importing of themes to not overwrite styles without comment, but - at least - to warn which styles will be overwritten if the import is continued and to offer the option of aborting the import <= This is a feature request solution to the bug
If it helps, here is an example of the situation:
Imagine a multi-file solution with 32 files. The AIM we ALL desire is to be able to easily manage themes and styles across these 32 files.
WE know the problems with themes, so we try to make all theme changes in File 1 and synchronize them to the other files.
However, what happens when
- a developer - who sadly doesn't know all the pitfalls of FileMaker Theme-synchronizing - creates a new button style for navigation buttons (mistakenly) in file 2, where he is currently working, (i.e. he selects a navigation button, saves the style as new style, then saved the changes in the theme),
- then he applies the new style to the 26 navigation buttons on 80 Layouts of file 2,
- and later, the developer-in-charge-of-themes then synchronizes the themes from file 1 to file 2 - OVERWRITING the theme in file 2?
Ok, the team has made a mistake - but they should not be punished for it! However the result of this (little) mistake is not just that the named style is removed from all (26*80 = 2080) buttons, but that all the buttons are reset to look like standard buttons, instead of just removing the association with the named style.
This 'little' error on the part of the poor developer (defining the style in the wrong file) has a disastrous result, requiring not only the style to be correctly re-defined in file 1 and imported into file 2, but also the (rapid!) repair of 2080 buttons, which look terrible.
Alles klar? ;-)
Thanks for the explanation.
Right now, a Theme is made up of Styles. Just to make sure I'm clear on your request, you want to separate the Styles from the Theme? And, when you import a Theme, just import the Styles without touching any Styles that don't exist in the original Theme. Correct?