Selectively Hide Tab Panels

We all know how handy tab panels can be. They help to organize data and reduce the amount of information on the screen at one time. However…not all users need (or should have) access to all of the available tab panels. Also, there are times when the data dictates that some of the tab panels are unnecessary or irrelevant.

Sometimes, it would be nice to selectively show (or hide) a tab panel based upon a user’s assigned privileges. Sometimes, it would be nice to rely on the data itself to determine which tab panels are visible (and which are hidden).

FileMaker 13 gave users “Hide” functionality…an object can be hidden when a certain condition is true. It is incredibly powerful and incredibly helpful. And…it can’t be used to selectively hide tab panels. It can hide a WHOLE tab control, but it CAN’T be used on just one of the panels IN a tab control.

There are some very nice options users have come up with to hide tab panels or tab labels. SeedCode has a nice method described at There’s another interesting method on the filemakerhacks site at

The method I’m presenting here shows two completely different methods to determine which tab panels a user will see: 1) a data driven model and 2) a privilege set driven model. Each model can be used and modified nearly at will. Using the privilege set driven model, one group of users could see only panels 1, 2, and 4. Another group could see only 3 and 6. Another could see all of the panels. Using the data-driven model, users could see panels 2 and 3 if a data field was set to one value. They could see only panels 1, 2, and 4 if the field was set to a different value. They could be shown panels 4 and 5, and if a different user changed the key value, their view would be changed so they’d see only panels 2 and 3. FileMaker would show, or hide, whatever panels the developer decided were appropriate.

Enough already…SHOW ME!

Basically, both models use three components stacked on top of each other and a script. In order, the components are:
1. “Conditional” tab control “Tab bar(s)”.
2. A web viewer which is hidden any time there is no need for a conditional tab panel bar.
3. The actual tab control.

This description will focus on the Privilege Set model. There will be one set of panels shown to “Admin”s, one set shown to “Odd Users”, and one set shown to “Even Users”. If a user logs in as an Admin, the Odd and Even conditional tab bars are hidden, as is the web viewer. The user will see all 9 panels:


If a user logs in and has the “Odd Users” privilege set, the Odd panel bar and the web viewer are not hidden, and the user will see only the Odd numbered panels (it could be anything. I chose odd just for this example.)


And, of course, if a user logs in and has the “Even Users” privilege set, the Even panel bar and the web viewer are not hidden. The user sees:


The process is completely transparent to the user. They login, and they see what they should (and not what they shouldn’t!). When a user clicks on a tab, a script is fired, and the user is directed to the proper tab panel on the Actual tab control object. Since the Tab bar is also a fully functioning tab control…it operates exactly as a user would expect…it goes to the panel that is clicked on. For instance, if a user clicks on Tab6 in the above example, the tab bar will show Tab6 as the active tab, and behind the scenes, the script will have advanced the actual tab control to Tab6. Panels can be added as needed, as can new tab bars for new privilege sets. Copy a tab bar, paste it, modify the hide condition and the tabs that are shown, modify the script, and you’ve got a new set of panels for your new privilege set.

Simple, effective, fully modifiable. You can have as many tab bars as you need, and they can all be modified as needed, too.


Why be careful? Layout fields that are hidden in Form or List views are NOT hidden in Table view. Make sure to disable Table view as a view option.

Why be aware? Even though something might be hidden from a user’s eyes, the objects are NOT hidden from scripts. You can script behaviors which access hidden tabs or the fields which users are not allowed to see. If a user action requires something to be done on a hidden panel…you can script it.

Why the web viewer?

The web viewer is simply an empty web viewer. When it is hidden, or if it is not added, then users can “click through” a tab bar to the tab panels below it. If Tab1 of the top tab bar is positioned over Tab1, 2, and 3 of the bottom actual tab panel, then a user could end up on a tab they were not supposed to see. The empty web viewer prevents that.

Show the components!

The process is this. Create your actual tab panel. Copy it, and paste it off to the side somewhere. Delete all of the fields from all of the panels. Shrink the height so that only the tab portion is showing. Delete tabs you don’t want to be shown on the tab bar. Create a web viewer, give it an empty URL, and uncheck all of the interaction boxes. Move the web viewer on top of the tab panel. Move the tab bar(s) on top of the web viewer and bring the tab bar(s) to the front. Add an “OnPanelSwitch” script trigger to each tab bar. The components will look like:


Select the tab bar(s), the web viewer, and the actual tab control, and align them to the top and to the left. Once the components are top left aligned…you’re ready to go. Editing is a bit of a pain…but this one layout provides a customized experience for each privilege set in your database.

What about the script???

Modify it as needed, but it’s basically just something that says…”Go here if this happens”.


You mentioned a data-driven model?

The Hide conditions in the privilege set model are set based on a global variable defined when the user logs in. The data-driven model works in much the same manner, but shows or hides tab bars based upon the value in a chosen field or fields. For example, you could show Cat-related tab panels for records identified as “Cat” in the field called “Pet Type”, or Dog-related panels for records identified as “Dog”.

Grab a copy of the file…


DataWorks works for you

DataWorks will work with your company to develop, troubleshoot, enhance, or revolutionize your FileMaker databases. Led by developer Dan Johnson, DataWorks has over 20 years of experience in working with FileMaker, the Adobe Creative Suite, and other technologies which can help automate your business.

Dan is one of very few FileMaker programmers in Iowa to be officially certified as a developer by FileMaker, Inc. When you work with DataWorks, you can be assured that your database is in the hands of a professional who has shown a commitment to his work, and will show you a commitment to your work.

Welcome to my blog.