ISO FileMaker Magazine

While there are some features which FileMaker provides natively, I often wonder how heavily they are used. One feature in particular is the Saved Finds feature, which is only available in Find Mode. It's a great feature in terms of convenience, however, its implementation is right on top of the funky developer'ish UI. It's buried many levels deep within multiple dialogs (if you want to modify any of the saved searches) and it's just not as pretty as developing your own within a dedicated layout or UI widget.

In this video and technique file, I showcase a system of how to provide the same feature of saving user searches. This is handled in such a way that you can make the searches available to whatever user/group or permission set you desire. Unlike the native features in FileMaker, it's not user account specific. Ultimately, it provides many more advantages of being able to run automated searches.

If your data is the kind where multiple routine searches are frequently re-run, then this technique will have what you need. AND, a big bonus is a tip about how to detect when a user executes a search vs when a FileMaker script does so and being able to determine the difference.

Out of the box, FileMaker is a really easy solution for inputing data and simply finding the results you want when searching that data.

There are, however, times when you need to break away from FileMaker's "solve all" solution of case insensitive searching. Times where you simply want to present some data within your user interface - without setting up extra relationships or fields. Or, those times when you simply need to search based on the case sensitivity of the data within a field.

In order to accomplish this, there are pretty much two different methods. In this video I show you how to accomplish this both natively and using the ExecuteSQL method. Using ExecuteSQL we gain a number of benefits and only need to be familiar enough with composing a SQL statement that will get us what we need.

Who doesn't like the simplicity of using a single field to search across many. That's essentially what Quick Find is. In fact, by default FileMaker makes the silly assumption that every field you add to a layout is something you want the user to be able to search.

Essentially, you want to take control of the user experience in terms of search and make sure the user is not only searching what you want them to search, but also able to search in a fashion which is both familiar and comfortable.

This technique file and video will walk you through the details needed to take full control of the Quick Find experience. You can enforce desirable effects such as sorted record sets and keep the user within the search field ready for multiple repeated search attempts.

By taking advantage of a variety of FileMaker features, we can create both an easy-to-implement and universally powerful Quick Find feature. Watch the video and use the associated technique file in order to have a better understanding of how Quick Find truly works within FileMaker Pro.

One of the most powerful features of any and all software is the ability to search and identify things which would be human impossible without computers. The ability to search for any given string and have that combination of characters be instantly presented is what has made our current world possible.

In this video, we take a look at FileMaker's default Find & Replace feature and we integrate this into our database systems. We then enhance that feature by implementing a Highlighting feature based on what the user is searching for.

With both the Find & Replace feature and the ability to highlight all occurrences, we have a pretty powerful solution for users who need to be able to modify and make changes to data based on what they're searching for.

As with all software projects, one of the biggest prices you'll ever pay is the accumulated technical debt. It's a cost which starts as soon as you make the choice to simply write a new script with every new feature you add into your FileMaker solution.

Thus, the trick with creating something which is easier to manage is to simply decide to limit the number of things you create. So, what does one do when you've made that decision? Well, you focus on using the available toolset, using great organization and creating a small amount of utility scripts in order to limit the number of things you would otherwise have to create.

In this video, I showcase an enhanced version of a system I designed a while back. It's a method for making simple, or even somewhat complex searches within the UI of your solution. You simply specify what you're searching for within the script parameter you're passing into the script. With the availability of JSON now, we have a very descriptive method of knowing what is being searched for.

With FileMaker Pro development, there are so many little areas which take a bit of time to investigate and discover. One of the more important areas is that of search and making sure you provide users with the results they might expect.

While using one of my own personal tools, I found that FileMaker itself couldn't find the result I was looking for when using its own Quick Find feature. I thought that was a bit odd and had to dig into the code to find out what the real issue was.

While the issue was tied to the type of data I was searching, it provided a great opportunity to explore how one would address this particular issue. Using FileMaker's search operators is something which every great FileMaker developer should be aware of. Fortunately, the descriptions provided by FileMaker's documentation helps us solve the issue.

Watch this video if you've got an interest in learning how FileMaker searches for content and how you solve unique issues which may prevent your system from providing the results you intend.

Making it easy for users to search for content is what your job is all about. If you're relying on FileMaker's default Query By Form method of searching, then many users may not know how to use the full functionality of FileMaker's search.

This is where you, as the developer, get to control how users interact with the data. By taking advantage of both FileMaker's QuickFind and the normal Query By Form, you can implement really nice features like an easy-to-use search bar.

In this video, we walk through the process of adding just such a search bar into the Custom Function database. If you're interested in learn about how you can take full control over the searching process then this video will provide you with a lot of insight!

Each time a new version of FileMaker is released there are more features and more information about what’s possible with the software. More functionality means more learning in order to take advantage of those features.

There are, however, core features which should be known by all developers. This includes knowing how to script Find mode and building an interface around the search functionality. Knowing how to script an omitted find request may not be super obvious unless you think of Find mode as being the same as Browse mode. Yet, scripting Find mode is exactly like scripting Browse mode. You can create an automated find which can be as complex or as simple as desired. It’s all a matter of translating what you would do with the normal native functionality and wrapping a user interface around it.

That’s what this video is all about. Taking the native methods for finding data sets and putting a user interface around them. When combined with a thought process towards lower maintenance costs, you can create some efficient methods of finding data.

As a developer, it’s often hard to get out of a mindset where your response of “It’s simple silly, you just search for a portion of the word, not the whole word.” to the question of a particular search not providing a user’s expected results.

This type of response may come from a user when they mention they know the user “Petrowsky” is in the database but it doesn’t come across verbally that they’re really searching for “Petrowski” - which obviously doesn’t match the version ending in a “y” instead of an “i”.

This level of understanding, that you can simply enter “petrow” in order to search for both variations, isn’t inherently obvious to all users. So the next best solution is to provide some type of filtering process. Something where the user can narrow down their list of choices to find out where the disconnect is happening.

In this video, we look at a sublimely simple script which makes this type of task an utter piece-of-cake. If you’ve got users who need to make routine selections on filtered subsets of data then the knowledge contained within this video will pay dividends beyond just knowing how to filter based on an alphabet letter!

As a software/database developer, one of your primary goals is making your solutions easy to use. This means users should be able to perform common queries by simply clicking buttons which run the queries automatically.

This is probably something you already do. But, the big question is this, “Do you make it easy on yourself for creating those simple queries?” Many developers will create a unique script for each of the various queries, and in some cases this is just fine. It’s when you start feeling the overwhelm of a growing list of scripts when you start to ask the really important questions.

Is it really possible to compose most of your scripted Finds using one single script? You’d better believe it is! In fact, if you abstract the searching part of your solution, it becomes very easy to create all kinds of queries, on demand, right there within the user interface.

When you abstract your search queries, you reduce the number of scripts within your solution and make it both quick and easy to automate the searching functionality of your solution.