Filtered portals Archives

I presented these demo files during a series of user group meetings in the Bay Area. My goal for each demo file was to incorporate the technique into an existing solution and think of it outside of the box.

Snapshot Link

In this sample file, there are two applications of Snapshot Link:

Launch file
Bookmark when closing

For the launch file, open up the solution. Once you’re at the opening screen with the “About” and “Demo” buttons, create a Snapshot Link and place it on your desktop. As long as the file doesn’t move, the Snapshot Link on the desktop can serve as your launch file.

For the bookmark, there is a script called “On Close” that runs when the file closes (via File > File Options). It shows a dialog and asks the user if his place should be saved. If the user agrees, the script puts a Snapshot Link to the desktop, that the user can click to start off where the database was last left.

Demo File: Snapshot-Link

Filtered Portal

In these sample files, there are two treatments of Filtered Portal:

New approach to tab control
Report management

It’s common to create a solution with tab controls, but what if you wanted to change the look? The layout “Sample Menu | Tab no Hierarchy” shows you how a filtered portal can enhance the user experience and control the tabs. This technique takes a combination of the following:

Hidden Tab Control (Fixed Width of tab = 0) where each tab has an object name
The table “Tab” that stores the tab display name, the menu group, the sort order, and the object name for each menu.
The script “SwitchTabs” takes the user to the correct object based on the object name stored in the Tab table.

The layout “Sample Menu | Tab” takes the technique to the next level, allowing a hierarchy of parent and child. The added tools for this technique work include:

A field in the table “Tab” called “Belongs To” that ties each record to its parent record
A global variable that contains the “Belongs To” value for the filtered portal

The other sample file for filtered portals shows how to use a filtered portal with global fields. Not only is the user interface clean, but the user has control over which reports he can see. You’ll notice the “Not isEmpty( )” in the Filtered Portal calculation. One of the things I’ve learned over time is that if the user selects nothing in a filter, he or she wants to see everything. It is counterintuitive but the expected behavior. Filtered Portals require quite a bit of trial and error.

Demo File: Filtered-Portal

Script Triggers

The latest version of FileMaker Pro introduces a few new triggers. In these sample files, there are several purposes for Script Triggers:

OnViewChange – Changing views (meaing layouts) with the Toolbar
OnObjectValidate – Providing feedback for erroneous data
OnObjectKeystroke – Limiting keystrokes and characters

In the first sample file, the script “Change in Views” is being triggered by OnView Change. If the user clicks on the “list view” from the toolbar, the script is executed, taking the user to a layout with the same data in a list view. The same applies in table and form view. The important part of the technique is consistency in the layout naming. Each one ends with the word that defines the layout view.

In the second sample file, there are three examples:

OnObjectValidate – Allowing a range based on the script parameter (Example: 1 to 10)
OnObjectKeystroke – Not allowing the user to type anything but positive numbers (including the decimal point)
OnObjectKeystroke – Not allowing the user to type anything but numbers (including the dash for negative numbers)

There is also an example involving the drop-down. One of the things my user discovered was the ability to type into the field if the drop-down wasn’t showing. By using OnObjectKeystroke, the user is limited to what keystrokes will occur.

However, it is important to note that individual keystrokes are allowed, even though they don’t produce a character. These keys include backspace, return, escape, and arrow keys. Removing these from the user’s capabilities would leave the user feeling handicapped instead of improving the interface.

Demo File: Script-Trigger

Recently, I’ve heard some push back when it comes to using filtered portals in solutions. The reason? Filtered portals are slow for large data sets. And this is a fair point. However, filtered portals and I have a close bond for reasons beyond their Brita-like tendencies of leaving the good and filtering out the unwanted. I love using filtered portals because they can enhance the interface, while providing flexibility for the developer.

Recently, a customer wanted to streamline a process and I decided to implement a checklist to get this done. Of course a simple checklist isn’t enough, as each step that uses the system should be clickable so that the user is taken to the right place to complete the necessary action. In the past, how would I have accomplished this?

Two Solutions

I can think of two solutions:

A slew of text boxes with scripts attached to each
A portal to a table that shows me the task and description with a rank field to sort them correctly

So before the birth of filtered portals, I could have accomplished what I want with #2 above. So why the admiration for the filtered portal? The filtering capability means I can use one table to house different checklists, and when I go to apply a portal with a new filter calculation to a new layout, a little copy/paste and I’m nearly done. All that’s left to do is change the calculation for the filtered portal. In pre-FileMaker 11, I would have created a different relationship for each type of checklist. Less table occurrences makes for a happier developer!

In the example of my customer, there are two different types of checklists: the input and the output. The input is all about how they enter the data. The output is all the “printables” – invoices, project details, project summary, etc.

Setting Up a Filtered Portal

Let’s talk technical – here are the fields I setup in my checklist table:

Type – identifies different checklists
Description – what the user sees
Parameter – what the script will use to perform the correct action and take the user to the right place
Rank – what the portal uses to correctly sort the checklist

How are my portals filtered? By the field “type.” An example would be as follows:

data_checklist::Type = "Input"

Nice and simple, right? Let’s kick it up a notch, á la Emeril Lagasse.

Imagine if you had an Issues database. What if a list of suggested questions or actions were provided, based on the scenario? Instead of hard coding the actual type, you can reference a field in your table:

data_checklist::type = data::category

Conclusion

So let’s step out of the proverbial box and into the world of possibilities – I’ve used filtered portals more for interface enhancement than for true data filtering, but what’s the harm in that? In fact, using filtered portals in this form helps the developer in adding flexibility via relationships and scripts. By abstracting the interface into a relationship and filtered portals, often modifying the interface can be as simple as adding a new record in a table.

Want to see these techniques in action? Check out my sample file! I’m using the table “Checklist” for the filtered portals in both examples.

3 FileMaker Demo Files