PLEASE NOTE: This is a reprint (if you will) of my post to my FileMaker Term Of The Day blog. The posting was so robust, I wanted to add it here as well. Thanks! Dwayne
CLASS: Working With FileMaker
VERSION: All Current Versions
A FileMaker button is normally considered an object on a FileMaker layout that has been assigned to perform an action when it is clicked upon. FileMaker is wildly flexible in how you can create buttons or what you can make a button on a layout. Here is a quick list ...
- created via the button maker tool found in the status area in layout mode
- any text string on a layout
- any field on a layout
- any graphic element on a layout
you should be seeing a bit of a trend here. Practically anything that can be put on layout can be turned into a button.
So perhaps the shorter list is what elements on a layout cannot be turned into a button. The only thing that leaps to mind is a particular tab on a layout tab panel cannot be defined as a button. Of course, that isn’t a show stopper, if that is what you want to accomplish. You can place an invisible button on top of the tab element for one technique.
FYI... an invisible button is a button that has no line color and it matches the background behind it. So it blends so well with the background, it is considered invisible.
FYI... Andy LeCates of FileMaker has been showing off a number of other development techniques for adding button like flexibility to tab panels. I’ve seen him demonstrate it at local FileMaker Professional User Groups (FMPUG) and at the last FileMaker Developers Conference.
FileMaker buttons on a layout are used to execute an action. This can include things like going to a layout, performing a find, sorting a found set and many more actions. Included in the list of actions is the ability to execute a script, which can run a number of actions (including subscripts) of it’s own. So really, a FileMaker button can do just about anything a FileMaker user can do in browse and find modes. Buttons don’t work in layout mode or print preview mode.
Before I leave you on this discussion (which is much more verbose than I imagined) is the current trend of FileMaker developers rethinking buttons in their solutions. I’m one of those developers and I might be in the minority here. The topic was first introduced to me by Dan Weiss in his Adatasol FileMaker podcast. It was in the context of custom menus and how they are a viable alternative to layout buttons. Many applications are menu driven in the operations they perform. So you don’t have to have a button heavy solution, you users might prefer a more menu driven environment.
You can do just about anything with a custom menu that you can do with a button. Custom menus can easily have sub-menus and it is easy to reposition menu options. Custom menus can be updated very easily and those changes can be propagated through out the system. Custom menus can be grouped easily and applied in a grid like fashion in your layout schema. FileMaker 9 is the current version of FileMaker as I write this. Currently, you cannot dynamically control what custom menus appear based upon a calculated result. However I would think this is a logical feature to appear in some new release of FileMaker Advanced in the future.
My favorite aspect about custom menus vs layout buttons is the avoidance of the layout nudge black hole. This can happen when you need to tweak a layout and then look up to see two hours of your life has passed you by. Custom menus can be added to any layout without the need to redo any part of that layout.
The creation of custom menus does require the developer to use FileMaker Advanced but those created menus will operation perfectly fine when executed by standard versions of FileMaker Pro.