Why do FileMaker style changes appear on only some objects?

1. Identify what you changed

Suppose you make a Save button green, but another Save button stays blue. That does not necessarily mean the theme is broken. You may have changed only the selected object, or the other button may use a different style or state.

Work in a duplicate layout in a practice file. Start with two ordinary buttons and no conditional formatting. That keeps the experiment small enough to explain.

2. Make a comparison you can trust

Place two buttons side by side and give them the same named style. Label them Save A and Save B. Check both in the normal state before editing. Keep their size and text similar so differences in padding or wrapping do not distract from the color test.

Change the fill of Save A only. Inspect its style indicators in the Inspector. If Save B stays unchanged, you have demonstrated a local change. Record that result instead of trying several unrelated settings at once.

Now ask what you intended: should only this button look different, or should every button with that named role change? A destructive action may intentionally need a different style from the primary Save action.

3. Save at the intended level

If the change belongs to the shared style, use the Inspector’s style controls to save the object changes to that style. Then review the other button that uses it. To make the revised style available through the theme on other layouts, save the theme changes as well. Claris distinguishes saving styles from saving themes.

For a new visual role, create a separate named style instead of redefining an existing one used throughout the file. A useful name describes the role, such as Secondary action, rather than just a color that may change later.

Before saving a widely used style, inspect other places that use it. A change that improves one large button may reduce contrast on a compact button elsewhere.

4. Compare the second layout

On another practice layout using the same theme, inspect a button with the same style name. Check its object type and any local formatting. A button bar segment is not automatically equivalent to a normal button, and a field object is a different kind of object again.

If the second layout uses a different theme, an identical-looking style name does not establish that it shares your edited definition. Confirm the theme name first. Do not switch the theme on an important layout merely to see what happens: theme changes can discard unsaved style changes and alter formatting. See Claris’s theme-change behavior.

5. Inspect the state that actually differs

• If the color changes only when the pointer moves over the button, inspect the hover state.
• If it differs only while a field is active, inspect the relevant field state.
• If only some records show the difference, inspect conditional formatting and its data conditions.
• If text has a different font or size, check the text selection and object formatting rather than assuming the fill style controls everything.

Return to the simple two-button experiment whenever the full layout becomes hard to diagnose. Fix one cause, then retest the states. Reapplying a named style can remove deliberate local changes, so do that only in your practice copy until you understand the effect.

6. Run a small regression check

Check both buttons, a second layout, normal and hover states, and the smallest button using the style. Save and reopen the practice file, then review again. If the result is right, document which style and theme were changed before applying the same deliberate change to a working file.

Finished result: you can explain why a change affects one object, several objects, or multiple layouts. Try this with Spring Garden Lite’s named styles, then compare the broader paid theme only if you need its additional design resources.

References

• Saving themes
• Changing themes

Use a practice copy and verify the result in your FileMaker version. Menu wording and platform behavior may differ.