Dedicated Find Layouts

Entering Find mode and performing Find requests is a crucial part of FileMaker Pro, but it's also one of the more difficult things to manage at the user interface level. As your solutions become more complex, Find mode will not be as intuitive for users: They might not have all the fields by which they want to search on one layout, or they may want to perform find requests on related data. Although FileMaker Pro can manage this task quite easily, users may be disoriented or confused by the results.

For example, say you've created a utility relationship that displays related data based on selected criteria or some temporary condition in the database. The fields sitting on your layout are not a structural one-to-many representation of your primary data architecture. Nonetheless, human users will intuitively want to hop into Find mode and have the process act on the primary relationship rather than your utility relationship.

Here's another example: Imagine looking at an author table with a related book-title field showing the most recent book written by that author. By definition, only one book can be the most current. Now imagine that someone is searching for an author who wrote a given book a long time ago. She is likely to click into the related book-title field in Find mode and be baffled as to why her search returned zero resultsor worse yet, she might not realize her mistake and might conclude wrongly that the data doesn't exist. (The book she's looking for is not the most recent, so the search fails.) Given that the fields on the right relate to only the most current book for an author, the search would be accurate but yield undesirable results.

Furthermore, there may be dozens of fields in your database, related and otherwise, but users will want to search on only a small handful of these 90% of the time.

To make the Find process as intuitive as possible, you can create a separate find layout. An additional nicety is setting it up to open in a pop-up window. Your users will remain in contextin other words, they'll see where they were in the window behind the current oneand will intuitively understand the process going on.

You can build Find processes generally in two ways, each of which is covered in the following sections.

Dedicated Find Mode Layouts

The first process is perhaps the most simple. Create a separate layout and populate it with all the appropriate fields specific to the table in which a find is to be performed. Take care to place primary related fields on these layouts: Using the book example again, you'd place a book title from a primary-key-to-foreign-key relationship between the Book and the Author tables. The find result would then properly return authors who wrote booksany books, not just the most currentthat matched the find criteria.

You can rely on users navigating to these find layouts themselves, along with entering Find mode and performing finds, or you can script the process. The scripted process would involve a button on your standard layouts to take the user to the special Find layout and enter Find mode. A second button on the Find layout itself would perform the request and return the user to the original layout and Browse mode.

This is a great way to give your users an intuitive process and shield them from unpredictable results. It's also a nice way to reduce the sheer volume of fields from which they have to choose in Find mode.

Script-Driven Finds

A more complex Find routine replaces the fields in the preceding example with global fields. Providing a dedicated Find layout will likely be something you may want to deliver in Browse mode. Instead of having users work with the related fields themselves (which in Browse mode would display actual data and pose, potentially, a problem if users didn't realize they had access to actual data), you can control access and the entire process using a script, and offer users empty global fields for entering find criteria.

This is a labor-intensive approach, and it relies on heavy scripting. As in the example in the preceding section, you need to bring users to the Find layout. This time, leave them in Browse mode. After their find criteria are entered, they need to click a Find button that then takes the system into Find mode, populates and performs the find request (by using Set Field script steps), and then returns the user to some proper results layout.

The difficulty here lies in replicating all the Find functionalities: inserting omit requests, extending found sets, constraining found sets, and working with multiple requests. We'd recommend using this technique only in rare cases when you want to fully control the user experience.