ISO FileMaker Magazine

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.

What would a database solution be without the ability to send email? Well, it would be a database solution without the ability to send email - but who wants that right?

Email is obviously an integral part of our modern day communication. And, despite what the Twitters, Facebooks and Instagrams of the world would have you believe, email is here to stay.

The easiest way to add email support to a FileMaker database is to simply use the Send Mail script step. But, that’s boring, and sometimes it doesn’t work. Especially when you’re using an email client not supported by FileMaker. The Send Mail step alone also has limited use when, most of the time, the intended objective is to integrate data from the database.

Therefore, we need to integrate the data from our fields. The easiest way to do this is to use FileMaker’s <<mergeFields>> right within the content of a text block somewhere on the layout, or off to the side of the layout, and then using the function GetLayoutObjectAttribute ( “My_Merge_Email” ; "content" ).

The problem we hit is that this is not user friendly. You don’t often give users the ability to edit layouts. So why not emulate the way FileMaker works with merge fields and simply do the same thing using data which is stored within fields?

This video showcases one of the most streamlined and easy-to-implement solutions for handling merge values into content stored within a field. Using the content provided here you’ll have an email merging and sending solution within mere minutes every time you need it!

When developing in FileMaker, the feature set it offers accounts for a good number of common tasks and provides easy solutions for most of these problems. There are a few issues, however, which FileMaker either hasn’t addressed or wants to leave up to the developer.

One of these is saving the current window state. This applies to tab panels, sliders and moving from layout to layout or when closing the file. The desired result, for the end user, is to simply return to where they left off when returning to a layout.

Obviously, it’s very comforting to come home to the same arrangement of furniture after leaving your home. If a user leaves a layout having made a complex selection of tab panels, sliders and button bars then it makes sense to be the courteous developer and put them back into the same state.

This video showcases a powerful method for saving the state of windows. It applies to all panel type objects and even when closing the file. If keeping your user interface nice and tidy is something you’re interested in for your own solutions then make sure and watch this video!