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 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 an example: Imagine looking at an author table with a related book title field of the most current 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 that field in Find mode and be baffled why it returned zero results ”or worse yet, not realize her mistake. Given that the fields on the right relate only to 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 context ”in other words, they'll see where they were in the window behind the current one ”and 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 an authorID-to-authorID relationship between the Book and Author tables. The find result would then properly return authors who wrote books ”any books, not just the most current ”that 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 globals . 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 complex approach, and relies on heavy scripting. As in the example in the previous section, you need to bring users to the Find layout. This time, leave them in Browse mode. After their find criteria is 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.