The Hidden Portal Technique - File Maker

Primary Database: Launch.fp5.
The Problem: Sometimes you want buttons or other interface elements to appear or function only when a certain condition is met, only for certain users, or only when there is certain data in certain fields in a database. There are a few ways to do this, like creating a calculated container field that contains the graphic of a button that appears only when the criteria are met, but then the button still acts like an invisible button even when the criteria are not met.
You could also just put the button there statically and control what happens in the attached script.
The Solution: Stack certain interface elements on top of a one-row portal. When the criteria you desire are met, this triggers a match field to populate, which then triggers this portal to become valid, which allows the interface elements stacked on top of it to become visible and functioning.

Launch the Launch.fp5 database and you’ll be presented with the data-entry screen for this solution, prebuilt. Notice the question “Is This a Delivery?” at the top center of the screen, with a Yes/No drop-down menu after it. On all new records, the default is no (this is a carry out order or whatever). Now, if you select Yes in the drop-down and exit the record (by clicking anywhere else on the screen besides in a portal or in another field) you’ll notice that a whole new box of information appears below the drop-down menu with fields to fill in, having to do with shipment information. This is a hidden portal. So how is it done?

A hidden portal is basically a self-related portal on the screen that appears (becomes valid) only when a user enters some data into a field that makes the relationship valid. The trick centers around the fact that in FileMaker the contents of a portal will appear only if there is a valid relationship.

Why would you want to use a hidden portal? Well, often a developer will make a data entry layout so generic (to cover every possible variable in the ordering process) that the screen becomes cluttered with a whole lot of fields that Jane Doe user would rarely use on a standard order. This clutter makes data entry errors easier to make, causes the learning curve for using the database to go up, and makes the order data entry process, on average, slower. So why not only show groups of fields to the user if they are relevant? Enter the hidden portal!

Another reason why the hidden portal trick can be useful is in a database system where different users have different levels of access and some users need to see more options or buttons than others. Rather than building a separate layout, you can use the hidden portal trick to display those options or buttons (in the form of layout objects) only when the user has the appropriate access.

One downside to the hidden portal trick can occur if you place buttons in the portal row. If the button is set to change the pointer to a hand when it is over the button, it will change to the hand even when there is no valid relationship for the portal. Clicking will have no effect except to confuse your users. The solution is to not have the pointer change to a hand, keep buttons out of the hidden portal, or use a separate layout instead.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

File Maker Topics