Hide Custom Menu Elements Dynamically
By Daniel Wood, 19 February 2011
When FileMaker 11 was released, one of the lesser documented changes in behavior concerned the defining of menu names when dealing with Custom Menus. When any menu element has an empty name, an interesting thing happens:
So, tell me what happens already!
Well, when an item has no name, the item disappears entirely from the custom menu, and from any custom menu it may appear in. Why is this so significant you ask?
Well for starters, this was not the behavior in FileMaker 10. In 10, any menu item with no name would still appear in the list as an item with no name (funny that).
Have a look at the custom menu set above. There is a menu in this which has no name, can you see it?
Here it is, did you find it? Well done! Ahem, so anyway, as you can see the menu is still there and still selectable.
Now lets see what happens when the same custom menu is viewed in FileMaker 11:
As you can now see, the menu is entirely gone in 11, it cannot be selected at all.
What does FileMaker say about it?
After having a rummage through the FileMaker 11 documentation of new features, I could only find the following mention here:
Users can no longer remove the item title and action checkboxes dynamically when the menu item is not based on a command. This means that it is possible to have a menu item have no item name or action.
I don't really understand the first part, but the last sentence would indicate that they acknowledge the lack of menu item name as a change.
Oh, the possibilities!
The potential to make use of this feature is limited only by your imagination. This is because menus and commands that are used in custom menus can have their name defined via calculation.
Have a look at the custom menu above. The Giraffe menu actually has its name defined in a global field in the solution, and the menu name is derived from that global:
So, whatever I enter into the global field is what the menu name is. If I remove the contents of the global entirely, the menu will disappear as it will no longer have a name.
Hiding Parts of Menus
Basically any component of a custom menu can have its name defined via calculation. Consider the following example:
The Giraffe menu contains both a command, and a sub-menu with further commands in it.
Here, I have removed the Lion commands name using the same global method. The Lion command no longer exists within the Giraffe menu.
Note:The Lion command has actually been removed from the Giraffe menu, and every other location it is used in the custom menu set, or any other custom menu set it is used in. The item either has a name or doesn't, and if it doesn't, it's gone everywhere.
Now having said that, given you are able to define an item name via calculation, you can build a calculation that will give the menu item a name under certain circumstances for example: based on your privilege set, layout you are on, flags defined in fields, global variable contents, etc. It may not disappear everywhere depending on how you build your calculation.
Hiding Sub-Menus
A sub-menu is simply a menu that is used within another menu. When this is done, the sub-menu expands to reveal its menu items contained within it.
Again, sub-menus when defined can have their name set via calculation, after all, sub-menus are simply menus.
Here I have the menu name in a global.
A cautionary table about sub-menus
One thing to be aware of if trying to show or hide a sub-menu is the following option you are given when using a sub-menu:
Here, I have defined a sub-menu Zebra. The Zebra menu has its name defined via calculation and the name of which is contained within a global field. Also, for this particular sub-menu definition, I have chosen to place it in the parent menu Elephant.
Pay attention to the Override Default Behaviors option. Here I have specified an overriding title for the sub-menu. You may expect in this situation that the sub-menu should appear as "MAXIMUM ZEBRA OVERDRIVE" under all circumstances, for an override should replace any default name for the Zebra menu.
This is not the case when the menus actual name is empty. In the case where the Zebra menu has no default name, the override is NOT applied, and the menu will still disappear.
This is unfortunate because the override item name would have been the perfect convenient way to keep a sub-menu in one menu, and have it hide in others.
When the Zebra menu does have a default name, the override will be applied.
Potential uses of this Feature
As mentioned earlier, the possibilities are endless. Here at Digital Fusion, we have used this feature in some of our custom solutions as a way to introduce a Developer menu into the solutions custom menus.
Rather than create separate menu sets for developers and users, we just have a user series of menu sets. Within each menu set is a Developer menu, whose name is only defined if the logged in user is deemed to be a developer (we check the privilege set name, and the user record for verification).
The end result is the developer menu appears for us, but not for regular users.
This has saved a great amount of time because we didn't need to replicate all of the custom menus for us. It also means we can get the best of both worlds, when testing and debugging a solution, we can use the custom menus the user sees, and we can also have access to our own developer menu which contains useful debugging tools.
I would love to hear of anyone else's ideas for using this feature.
Final Thoughts:
While this is a lesser documented feature of FileMaker 11 - to the point of barely being documented at all - I think it is one of the coolest features and one that has limitless applications.
... Just be sure that you are building it for solutions that use FileMaker 11, otherwise you may not get the desired effect!
Example File
Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution.
Something to say? Post a comment...
Comments
Eric Ruff 12/01/2013 9:38pm (12 years ago)
OK, here is an update. The "install on" setting for a menu is evaluated at the time the menu set (of which that menu is a member) is installed. Let's say it evaluates to boolean "1" -- the menu is installed. If you later change the condition for the "install on" so that it is a boolean "0", then you can delete the menu from the menu set by re-installing the same menu set. The menu item does not get installed. To the user, it just disappears. Of course you can alternate the appearance of two different menus with the same name by changing the "install on" condition and then reinstalling the menu set. It works well and there is no "blinking" of the menu set on the re-stall, so it looks smooth. If the two menus have the same name, you can't tell anything has changed, until you inspect the menu items. In my case, I have a check mark (Option V) that appears and then disappears from the menu item to show if it is enabled or not.
Eric Ruff 12/01/2013 9:06pm (12 years ago)
"Nice to know we'll still be able to turn off menus dynamically." I am not so sure. I am finding that I can dynamically turn menus ON, but not OFF, which is too bad. The setting "Install On" lets you control if a menu is installed or not, but once installed I don't think you can get rid of it except by installing a completely different menu set. I want to mimic the "?" check mark next to a menu item indicating whether that feature is enabled or not. So I was going to have two different menus, with the same display name. One menu would have the menu item "? Feature enabled" and another menu would have the menu item " Feature enabled" with no check mark. Of course the text you use is unimportant. But I wanted to "install" or "not install" the menu according to whether a field was "Yes" or "No" and I can't seem turn turn one one menu and turn off the other menu dynamically. I don't really want to completely change out menu sets, but may have to. Maybe I am missing something, happens all the time.
Chuck Ross 17/04/2012 9:54am (13 years ago)
Hadn't done any investigating, so I appreciate the tip. Nice to know we'll still be able to turn off menus dynamically.
Daniel Wood 17/04/2012 9:43am (13 years ago)
Hi Chuck, during the testing program for FileMaker 12 it was noted that this "feature" was not going to be supported in FileMaker 12 - however they have made a change to custom menus which should hopefully allow you to achieve the same thing.
In the custom menu settings there is now an "Install On" option you can use, and you can specify a calculation that if true, means the menu is installed otherwise it is not. So rather than put your test in the menu name itself, this now lets you put it in a special option specifically for the purpose of showing/hiding menus. By default the calculation for new and converted menus is "1" so they always show.
Chuck Ross 17/04/2012 2:29am (13 years ago)
Unfortunately, it looks like the behavior in FileMaker 12 has returned to that of FileMaker 10. I converted a solution I'm making to 12 and the invisible menus showed up again with blank name. This is really unfortunate, since custom menu sets could be much simpler to develop with this feature. I'm sure FileMaker considered it a bug to be fixed, but I think the behavior of 11 was much better, especially for advanced solutions.
Jonathan Fletcher 18/07/2011 12:24pm (13 years ago)
Forgive me for taking the discuss in a slightly different direction. Concerning the idea of showing the status toolbar at all: Kate Lee led a great discussion at the last Pause on Error on that very subject. Consensus at the end of the session was to lock it closed. I agreed with the group based on the problems discussed. Chief among them was that the user can add other buttons to that area that may do things you don't want.
But now that I've seen that you can override all the possible things (I think) a user can do with those tools, I think a revisit of that idea might be in order.
Jonathan Fletcher 18/07/2011 12:05pm (13 years ago)
I was just about to mention that it does not remove the function of a status toolbar icon if the menu is blank, when I noticed David's post above. David you CAN capture and redirect the icon's action with a menu action override.
In addition to turning menus on and off, I found it quite useful to rename the Record menu items (New Customer, Delete Customer, New Account, etc.) and use a script to capture the command and redirect it to my new record routines. It even changed the name of the toolbar icons! (Pretty cool in and of itself!) The problem arose when I tried to turn the menu off (as David mentioned): the icons reverted to their former default names and behavior.
So the moral of the story is either you turn off the status toolbar entirely or that you still need SOMETHING in the menu to capture the toolbar icon's action. Creative menu item naming to the rescue.
Wind 18/07/2011 9:13am (13 years ago)
Dude, right on there brthoer.
Daniel Wood 30/05/2011 8:46pm (14 years ago)
Cheers Chuck, glad you have found a use for it :-) If you know how to get it onto page 1 let me know hehe.
Chuck Ross 30/05/2011 8:33pm (14 years ago)
Given how useful this feature is, I've no idea why it was on the second page when I Googled "filemaker custom menus". :) I have a system I'm building right now and will use this technique extensively to set menu titles that should be hidden from non-administrator users as well as your mention of using the technique to hide menus from non-developers. Thanks so much for the discovery!
David Jondreau 26/03/2011 6:57am (14 years ago)
Useful info.
Unfortunately, you can't get items on the toolbar to go inactive with this method. So you can't toggle the "New Record" button on and off.
Volker Krambrich 10/02/2011 1:18pm (14 years ago)
Thanks for sharing (via LinkedIn) and investigating that behavior. I stumbled over the fact that a not named item is gone, but did not think of the opportunities, they were just out of sight ;-)
We did experiment with dynamic menu (item) names through calculation in a multilingual solution. Based on user preferences menu (item) names change with the chosen language. This experience together with your findings opens for really context- and user specific menus.
Daniel Wood 10/02/2011 9:19am (14 years ago)
Hi HOnza, in my experience using it as a way to generate a custom menu, there is an initial performance hit as each related record must be evaluated & downloaded from server to client machine in order to render the menu. But once that is done, it is cached and further accessing of the menu is instant, it's just that initial download hit it takes. However because my navigation menu is based off the exact same relationship as my navigation bar, the user sees no additional performance hit than they already have because once the nav bar is loaded, so will the menu be.
Cheers!
HOnza Koudelka 10/02/2011 9:13am (14 years ago)
The GetNthRecord idea is neat! I am only wondering how it could affect speed of the whole solution...
Paul Spafford 10/02/2011 8:12am (14 years ago)
This is cool, Daniel. I love that I can now (for the most part) use one menu set for the entire solution, just hiding what some users may not need.
Daniel 10/02/2011 7:50am (14 years ago)
Cheers for the comments Bart, HOnza, Michael, Stephen & Jonathan, glad you found the article interesting & potentially useful :)
As an extra, consider this possible use: How about building a menu using records in a related table (or current table). You can use the GetNthRecord calc to determine the menu items names. One drawback is you have to manually create as many menu items as you think you may need, but the good thing is the menu items which have no equivalent record won't show as GetNthRecord won't yield a result. So you could add 500 menu items for example, and if you had 50 related records, your menu would only show 50 items not 500...
We have used this particular technique in one of our solutions as a method of navigation where "screens" are kept in a table, and every user had their own accessible screens available via custom menu (this will also be mentioned in a further followup article to the Navigation article).
Cheers!
Jonahtan 10/02/2011 7:45am (14 years ago)
That is so cool, Daniel. Thanks!
Stephen H. 10/02/2011 6:27am (14 years ago)
Thanks for pointing this out. I was about to tackle a group of custom menus for a client based on permissions, and this will greatly simplify my work, allowing me to control visibility via calculation rather than building multiple CM sets, a chore I do of necessity rather than choice.
Michael Rocharde 10/02/2011 4:58am (14 years ago)
This is terrific stuff, Daniel. Very imaginative and I think, very useful. Thanks for sharing it with the community.
HOnza 09/02/2011 11:49am (14 years ago)
Very useful. I agre with Daniel, huge time saver for designing dynamic menusets. Debugging can be easily handled by using a special custom function as an override. Just for clarification - custom function is safer than global variable for override because unlike global variable it cannot be modified without full access.
Daniel 09/02/2011 9:05am (14 years ago)
Hi Bart, thanks for the comment!
I guess in terms of time saving it is less about time saving when debugging, and more about time saving in building the custom menus themselves. Consider a menu with about 30 different commands in it for a complex screen, and within that there is a mixture of various commands accessible only for certain types of users.
This method would let you construct just one menu with all of those actions in it, and access to certain elements is controlled outside of the menu itself, via external methods that effect the names of those commands in the menu.
If it were to be done another way, you would need an entirely different menu set for each type of user, have to install it on the layout each time they visit depending on what user they are, and so on. While it's possible, it does mean you have to replicate most of the menus so you end up with different versions of what is essentially the same menu.
Cheers.
Bart 09/02/2011 8:47am (14 years ago)
Pretty slick, Daniel. but without having gone through a solution using it yet, I really question it as a time-saver. As a tool to jump back and forth, it doesn't seem like it adds anything to a re-login or changing the global assignment of the user from developer to normal user and back again. That said, I'm going to look at it more closely. I really appreciate the outside-the-box thinking on this.
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments