Using Hidden State For Validation

Hiding a button to provide feedback

Do you ever use FileMaker’s layout object’s “Hide object when” behavior to hide a button until some criteria have been met? It’s a nice way to provide feedback to the user and makes for a good user experience. But what you might not know is that you can use hidden state as a way of validating whether a script can run. Here’s how.

Let’s say you have an input dialog or a form that must be filled out completely and with valid values before the user can save the info in it. We like to display a “dead” button until all the criteria are met, after which the “dead” button will be replaced by a “live” button. You can do this by stacking the “live” button on top of the “dead” one and then use the “Hide object when” in FileMaker’s Inspector in the Data tab.

The examples below show an input form in a popover for recording a loss from a nursery management software we developed. The “Save” button only appears to be live when all requirements are met.

In the first 2 examples above the Save button provides feedback to the user telling them that they can’t proceed. In the 3rd example, the user can see that all criteria have been met because the live Save button is displayed.

The calculation for hiding this particular button is shown below. The last thing you’ll want is to have to maintain it in two different places. Keep this thought in mind because I’m leading up to the part where we get around this undesirable duplicity by leveraging the GetLayoutObjectAttribute ( ) function.

Case(

IsEmpty( GLOB::gDateGeneric );

IsEmpty( GLOB::zkg_lossTypeID );

IsEmpty( GLOB::zkg_lotStatID );

ValidateIsIntegerWithinRange( GLOB::gQtyProduct; 1; $$qtyMax )=0;

Choose( GetAsBoolean ( GLOB::zkg_lossTypeID ) ;

IsEmpty( GLOB::gTextGeneric[2] );

0 );

0 //if we’re here, don’t hide it

)

All was going great until users got their hands on it

So far so good. We’re providing really nice user feedback, right? What could possibly go wrong?, you might ask. Users. They’ll always figure out a way to break things (they really don’t mean to, it just happens), and here’s how they can end up with a live Save button when the script shouldn’t run.

In the screenshot to the right you’ll notice that the Quantity field is empty, yet the live Save button is displayed. This means that the user can trigger the script that isn’t supposed to run if that field is empty. So how on earth did we end up with a required field empty AND a live Save button?

Easy. There was a value in the field, which led to the live Save button displaying, but then the user deleted the value in the field but left the cursor in the field. The calculation for hiding the live button has not been triggered to evaluate yet because the field was not exited.

Self Preservation Is Also A Mother of Invention

Now I faced a dilemma. I had a very nice UX design for buttons, but it had a major flaw that I was addressing with duplicate code. I considered putting the calculation in an offscreen text object and then using the Evaluate () function. But this approach was fragile due to the need to reference a hard-coded object name in multiple places.

The next option I considered was to duplicate the logic at the beginning of the script that the Save button triggered. If the calculation for hiding the button resolved to be true, all I had to do was exit the script. I felt it was a step in the right direction, but I still wasn’t happy with it because I was still duplicating the calculation.

Better (but still not great)

Even though I wasn’t pleased with the last option, I felt it was the least worse, so I started to implement it when the proverbial lightbulb came on in my head. Why don’t I just commit the record, which would result in the live Save button being refreshed to its proper hidden state? Then I could use GetLayoutObjectAttribute ( “myButton” ; “isObjectHidden” ) to determine if the script can continue or it needs to be canceled.

The following shows a segment of the script that tests whether the button object is hidden or not. If it’s hidden after the Commit step, then the script exits and the user sees the form with the dead Save button.

Problem Solved

Now the hide logic that’s being used to display or hide button objects is also being used to determine if the script met the criteria to be triggered in the first place. And the logic is only in one place, making it super easy to maintain. The only potential downside I’ve been able to think of to this approach is the fragility of the hard-coded button object name. If the object name’s changed then it breaks. There are ways of testing for the existence of an object name on a layout and I may eventually incorporate some kind of a test for that into scripts that use this technique. But since we’re pretty good about not changing the names of objects without running them through a FileMaker analysis tool like FMPerception, BaseElements or Inspector before making a change like that, it’s a low priority.

User experience design is an important consideration in all apps we develop. So is keeping things as simple as possible from a development standpoint. I hope you found this to be an interesting case study of how challenges can arise when trying to provide a good user experience, and how a little “outside the box” thinking can lead to ways of overcoming challenges while maintaining simplicity.

If challenges in your FileMaker solution are stumping you, drop us a line. There’s a good chance that we’ll be able to either teach you the skills to overcome those challenges yourself or do the work for you.

Share This Post

Kent Searight

Ever since the day a coworker handed Kent a couple of floppy discs that were labeled FileMaker Pro 2.0 he's used the FileMaker platform for developing solutions for improving workflows and data management. When he's not figuring out ways to help businesses improve efficiency he can often be found kayaking off the Oregon Coast, hiking, birding, scuba diving, traveling or home-brewing a batch of beer.