I haven't found any evidence / documentation that this is possible, but can individual menu items in a custom menu be programmatically (by calc or script) enabled or disabled (dimmed)?
I believe you can do what you want. Create two menu items and give them the same name. Assign what you want to one of the items and then assign a command that the privilege set is not allowed to perform. Then set up the conditions when each item will install in the menu. The conditions should be opposites ( = yes. Vs <>yes). Only one of the items will install Based on the condition. One will be gray and the other black.
What are you trying to achieve? It may be possible another way.
Users of applications are used to the common user interface paradigm that when a function isn't available, its text is shown "grayed out" and cannot be selected. "removing" menu items that are contextually not available is confusing to an end-user.
FileMaker Pro itself follows this UI convention: the INSERT menu (all items contextual grayed out), the EDIT menu (Undo/Redo, Cut, Paste, Clear, Select All etc.), VIEW menu (View as Form, View as List, View as Table -- depending on layout).
Well, it's not currently available.
For a moment, I had hoped that the menu items would respond to "TextColor"...
This is a source of debate in the UI / UX community. There are some who, like yourself, feel that items should remain visible, but ghosted, when they're inappropriate. There are others who believe that users should not be allowed to see options that aren't currently available at all.
The first camp argues from the standpoint of consistency: If a user learns where the options are, then when they're available, he doesn't have to hunt. The other camp argues from the standpoint of visual clutter and distraction. If users see things that aren't allowed, it just leads them to believe items are available when they're not (even if they're ghosted), and distracts them from what is actually available and allowed.
The latter is a more modern paradigm. FileMaker was first developed when ghosting menus was the norm. If you use web sites (for example) nowadays, you'll find a lot more cases where options are simply not there if they're not available.
Both positions have merit, and I'm not going to get into the debate here. I merely point it out to explain that, perhaps, the working of Custom Menus is simply a different design philosophy (albeit probably accidentally).
So I've been designing User Interfaces for 35 years -- this is the first I've heard of this debate. And while I am the first person to push for improving on "standard" UI convention, I guess I'm confused because the current modern consumer operating systems (Mac OS X and Windows) both adhere to the graying out UI convention.
I think I can understand why, from a programming perspective, the developers of the FileMaker Pro environment may have more difficulty contextually graying out items. But as an END-USER, here's how I would react if suddenly I only saw "Paste" in my Edit menu -- and Cut / Copy / Clear / Select All were GONE:
...I would react (seriously) like "who the #$%K designed this software?!"
Back in the "old days", we used to similarly debate if adding / removing ENTIRE menus made sense, depending on the context. As today, there are merits to that discussion for both approaches -- and fortunately FileMaker's Custom Menus supports either approach.
So I wish they would similarly support contextual item graying.
I can assure you the debate is current, and quite lively. See Re: Best Practices: hide or conditional formatting for a recent thread on this forum.
If you want the feature, by all means, submit it as a product idea. No reason not to.
OH -- debate amongst FileMaker developers.
Thanks -- I'll read up on that.
I just tested this. Doesn’t seem to work. The menu item still appears, but throws the “no access” error when selected.
Works on my computer. I use New Record as the command that wouldn't work with the privilege set. Sounds like you tried using something that was related to access privileges like a go to a record or layout that you don't have access.
No, I used a blank script I explicitly told the privilege set it didn’t have permission to run.
I just tried it using your suggestion, and the explicit command does work as you specify. So it seems this works, but only with native commands.
Totally works on my computer! I created a privilege set that had everything except "allow exporting". Then I set the menu item to "Export Records..." -- and you were right -- it totally disables the item, on both Mac and Windows.
Wow. Great insight! Thanks!
The thing that I love about Filemaker is when somebody says something can't be done, there usually is a way to accomplish what you want with a little outside of the box thinking.
Yep -- allowing any value to be set via calculation really extends the power of customization!
Do you know if there are any of the "extended privileges" that if not enabled would prevent some "exiting" FileMaker command from being enabled? It would be great to not hamstring "export" (which I likely wouldn't expose as a menu item, but may need internally in the runtime).
EDIT: Not sure about any of the "Extended Privileges", but for my use, only the guest account is enabled in the runtime, and therefore the user isn't allowed to "change their password". Thus, the FILE > Change Password... command is PERFECT for this use.
Retrieving data ...