Estimated Time To Read This: 2 – 3 minutes
Recently, Alan discussed how flexible FileMaker can be, by letting you select a different custom menu for each layout. While that kind of flexibility is invaluable, managing a large number of custom menus can be quite tedious. I think it’s also rather noteworthy that FileMaker Pro’s custom menus can be set up in such a way that you won’t need multiple custom menus in order to accurately represent each layout. Since the dialog box for defining a custom menu lets you override a menu item’s name, I should point out that you can take advantage of FileMaker Pro’s calculation engine in order to derive the name of the menu item. This gives us a couple of excellent benefits:
Naming Items To Match Current Context
Let’s say you’re new to using a FileMaker database, and the one you’re viewing is a CRM (customer relationship management) system. If you were looking at a list of contacts, and you see a menu item that says “New Record”, it might not be immediately obvious that by clicking it, you’d be creating a “New Contact”. In order to make your menus more user-friendly, you might want to rename “New Record” so that it says “New Contact” instead. Some developers create a global field or variable that will be populated with the current module’s name (Company/Contact/Activity/etc…). Using a field/variable like this and the calculation engine behind the custom menus, you’ll be able to have one menu that will be able to accomodate all of your layouts.
Security-Light
Probably a lesser known use of the calculation driving the menu item’s name is one where the result of the calculation returns a NULL value. Whenever the item’s name results in a NULL value, the menu item will not appear within the menu. What this can mean to you is that you can take advantage of this feature to remove particular menu items from the menu based on somebody’s privilege set for instance. This gives you a sort of ‘security-light’ in your solution.






