We’re thrilled to announce the official, “integration-ready” version of LOgiCATOR. LOgiCATOR is a modular search interface for FileMaker that can be easily integrated into new or existing solutions. It’s designed to help users locate data with logical precision, via a powerful yet intuitive interface for searching across FileMaker tables. This article includes a download link for the module and demo file, describes what’s changed since the preview version (a lot), and explains how to integrate LOgiCATOR into your FileMaker solutions.
At the Custom Web Publishing (CWP) user group at FileMaker DevCon 2017 in July, a number of speakers (and a big thank you to everyone for a great session!) discussed solutions they’ve taken or investigated for making CWP apps compatible with PHP 7.
At Beezwax, we have a client project with a requirement for PHP 7 compatibility, but many of the available approaches were closed to us due to various constraints, so we came up with this solution.
In Part 1 of this series, Introducing LOgiCATOR, I mentioned that LOgiCATOR grew out of a search interface I developed for a project several years ago. In ways we’ll briefly consider here, it wasn’t extensible, but all that has changed. As that early search interface grew into LOgiCATOR, it made a quantum leap in context independence. The reason we were able to accomplish that can be attributed to a powerful synergy of FileMaker card windows, JSON, window improvements, new functions, and the Layout Objects window — in short, FileMaker 16!
Visit the LOgiCATOR page at Beezwax.
We’re excited to announce the release of LOgiCATOR, a new modular search interface for FileMaker. It’s designed as a module you can drop into a FileMaker application and, with minimal configuration, add a rule-based search interface to any number of layouts in that solution. LOgiCATOR is also a springboard for learning about some great new design and integration features of FileMaker 16, like card-style windows and native JSON.
Visit the LOgiCATOR page at Beezwax.
While working on the third installment of Fun with FileMaker Button Bars, I was served a reminder of why it’s good to test the stuff you write about using the latest software updates (even if they just arrived that very morning).
Continue reading “Why It’s Always Good to Test Things with the Current Version of Software (When Writing a Blog Post)”
In Part 1 (“Check Please,”) and Part 2 (“Expert Panel,”) of this series, we had some fun doing things with button bars that showed off some of their unique usefulness within the FileMaker design-layer toolbox. Often as not, your button bars are going to include icon labels, with or without a supporting text label, and you want those icons to look great.
Highlighting insight, performance and collaboration
Wow! InspectorPro 6 is finally here. Can’t even believe it. It was such a massive undertaking. Lots of great new things and many improvements. Really proud of this release. In the immortal words of the late Steve Jobs… “This is our best version ever”.
The Lesson of Context
One of the first lessons I learned with FileMaker is that of context! Layouts, reports, calculations, scripts, and so on all act from the perspective of a single Table Occurrence (TO) — the “context” — pulling in data from related tables as needed.
Generally, the record set being acted on is the set of records in that context table occurrence or a found subset thereof. There are a few exceptions to this, however, and today we’re going to explore one of those.
A few years ago, I worked on a FileMaker project where the client told us that every week they need to import about 7,000 rows of data that represent some information that this company uses. And every week there might be some modified records, some records that don’t show up any longer, and some new records that hadn’t already existed. For this example, let’s just call it this data “Products”.