ISO FileMaker Magazine

Getting fresh icons into a FileMaker solution has always meant friction: hunt down the right SVG on an external site, sort out whether it will actually work given FileMaker's dated SVG support, convert or rework it as needed, then manually import it one at a time. If your button bars look tired and swapping their icons feels like it costs more effort than it's worth, this video shows exactly why that process no longer holds.

Watch as a single plain-language prompt sets off an entire icon replacement workflow. The video demonstrates how an agentic process reads a button bar directly from the clipboard, identifies every embedded icon, pulls in appropriate replacements from open-source icon libraries, handles the compatibility conversions that FileMaker's older SVG standard requires, and delivers a fully updated button bar back to the clipboard, ready to paste. Attached scripts, conditional formatting, and all layout logic survive the swap completely intact. What used to be a multi-step manual process across several tools collapses to roughly two minutes of watching things happen.

The full version goes deeper into the mechanics, including how FileMaker's SVG limitations shape what conversions are necessary and how to structure icon requests to get accurate results in bulk. There is also a thorough walkthrough of a community-built FileMaker tool dedicated to icon management, covering its strengths, its current gaps, and where an agentic workflow picks up the slack. The session closes with a look at how this entire capability is embedded directly into an open-source agentic editor setup, so you can replicate or extend it inside your own solutions.

Even to this day, after providing FileMaker-related technical education for many years, I still see solutions with less-than-optimal structure and storage. When it comes to graphics, “all things add up.” The cumulative cost of data or technical debt often comes back to bite you when you’re trying to refactor an old solution to meet modern standards.

This video showcases what I know about storing and using graphics within your FileMaker layouts. If you’re unaware of how large images impact performance, you might end up needing to update them in a million different places - unless you know the trick for better storage. For example, not realizing that you’ve added a 4MB image instead of an optimized version that can be transferred as part of CSS through WebDirect can make a huge difference in performance. These are the kinds of small but crucial details that can significantly improve your solution overall.

That’s what videos like this are all about - understanding how things really work. How is the data stored? Are things being duplicated unnecessarily? If the thought of updating hundreds of graphics is something you’d rather avoid, then it’s time to take full advantage of the tools available to us. Let’s optimize our graphics knowledge.

When FileMaker, Inc. released the new theming system for FileMaker Pro a while back, they made one of the best decisions possible for a development platform. They chose to go with an industry standard instead of rolling their own solution.

The standard they chose to use was CSS (Cascading Style Sheets). While their implementation was specific to the platform, and the whole "cascading" part didn't really apply, the choice was a good one.

Today, the upside is the fact that it's the same language of the web. The same which is used to provide ultimate control over how everything looks on a given web page. Essentially, full power and control to the designer or developer. The downside, in FileMaker's case, is they can only expose certain aspects of the CSS as their internal development resources allow. They have to keep moving the product forward in other areas as well as the user interface.

So, knowing that CSS is behind the scenes, there are certain things we can do to modify the look and feel beyond what FileMaker's Inspector palette exposes. This video is about a certain insider trick which can make your use of a company logo infinitely easier when it comes time to make a simple change down the road. Check it out!

What would software be without icons? Would it be like looking at a tree without leaves? For some reason, a tree just looks more like a tree when it has leaves. Right?

So, this video is about how FileMaker uses SVG icons within it’s buttons. If you’ve always wondered how to make the most of FileMaker’s support of SVG icons, then look no further. In this video I’ll show you my own personal workflow for creating and integrating icons into a FileMaker solutions. You can integrate icons into your solution in a surprisingly quick fashion if you’re willing to get familiar with a bit of node and gulp.

Of course, even if you have no desired to install node.js, you may very well find tips and tricks which will help you expedite the process of integrating icons.

For me, it's always been one of those itches I could never quite scratch. You know, the fact that in order to show some of your user interface graphics you needed to store these graphics within your database - along with your data.

In fact, it's pretty much accepted that you create container fields, many times within a dedicated table, to store graphics and resources.

The issue I had with this approach was not that it needs to be done, but the fact that the user interface graphics were not separated out from the rest of my data. I wanted to be able to simply "draw" graphics onto the layout.

Well, this itch can now be scratched with FileMaker 13's new Base64* set of functions. While you still need at least one container field in order to render your graphics, the new additions have reduced the number of fields in total.

Watch this video to gain a full understanding of how this works and just how easy it is to integrate into your own solutions!