PDF Estimated Time To Read This: 4 – 6 minutes
It’s common among systems that are used by many people of varying security levels, to have buttons on your layouts that some users can execute and others can’t. If you’re designing for such a system, then you’ll probably want to provide the end-users of your system with some kind of visual feedback that will let them know whether or not they can perform those actions.
There are various ways of tackling this task, but all of them revolve around defining a set of conditions that will ultimately determine whether or not the end-user has access.
For example, if you’re dealing with a native FileMaker button, then you can use conditional formatting on that button so that it looks greyed-out when your conditions are met. But what if you’re not dealing with plain text? Let’s say you’ve gone the extra mile and you have graphical buttons on your interface. In that case, using conditional formatting to grey-out your text might not be an option.
One common way to handle this is through a technique commonly referred to as “The Hidden Portal Trick.” This is accomplished by creating a new relationship on the graph that can hide or show the button whenever your conditions are met, displaying a single-row portal that looks into that relationship, and drawing your button within that portal.
While the hidden portal trick gets the job done, and is able to conceal both images and text, it can clutter up your relationship graph with extra table occurrences, and can complicate what is going on. An unfamiliar developer trying to figure out the system would have to first find out that there’s a portal there, inspect the relationship graph to see which two tables are involved, then inspect the match fields on both sides; in some cases there might also be a script to inspect that sets these match fields.
There is, however, another technique that can be used that’s a hybrid of the two. The technique that I’ll describe uses conditional formatting (much like the first technique), and has the ability to hide graphics on your layout (like the hidden portal trick)… and it can do all this without adding any new table occurrences to your graph.
Here’s how it works:
Let’s assume that the button you want to hide is already present on your layout.
First, you’re going to want to draw a native FileMaker button on the layout that completely encompasses the image you want to hide. It will look rather clunky, but we’re going to fix that.
Change the effect to “No Effect,” the line size to “None,” and the fill type to transparent. You should no longer be able to see the button encompassing your image, but you will see that the handles selecting it are actually larger than the image itself.
All that’s left is to apply the custom formatting:
Here, you’ll need to specify your condition in place of <<User Does Not Have Access>>, and make sure that the fill color selected matches that of the background of your layout.
If you know me, you probably know that I’m an optimist, so for this example I’ve illustrated optimistic programming. Essentially, the underlying image/button is always displayed unless the user does not have access to it. In the event that the end-user doesn’t have access to see the button, then the fill of the encompassing button changes from transparent to solid white, hiding your button.
In summary, this is a simple way to hide anything on your layout from specific users that won’t clutter up your schema or relationship graph. To top it all off, since this is an interface trick, it’s rather nice that it keeps all of the programming right there where it belongs, on the layout itself.
