Definition: The top 10 scripts are the top 10 Scripts showing in the scripts menu.
These top 10 scripts should “first do no harm” as they can be accidentally called from keyboard shortcuts.
Your top 10 scripts can include scripts that do something useful (and safe), or do nothing, for example: Script #08 with 0 steps.
You might add some blank scripts to fill up the top 10 spots. If someone later adds a potentially damaging script, it will likely show up below the top 10, will not have a keyboard shortcut, and will be harder to call accidentally.
Better yet, you can make your top 10 scripts useful…
Here are some of the ones that we like:
Go to MainMenu (System Wide Home Screen/Dashboard)
Go to Detail View (goes to Detail view for the table that you are on)
Go to List View (goes to List view for the table that you are on)
Varies
Varies
Varies
Varies
Varies
Varies
Help Request (keyboard shortcut is a mnemonic for “call the operator")
What are your favorite scripts to include in the top 10?
I do not like having scripts shown from the scripts menu.
I kind of like the idea of having 10 placeholders so if someone adds a new script, it does not show, but that also means the users are exposed to those 10 values and will be asking about ‘What are those for?’. I don’t like having to tell my users to look elsewhere on their screen.
All in all, I guess my favorite solution is to use custom menus to remove the script menu altogether. Once you are using custom menus, it’s easy to put any scripts you want and organise them in submenus and put them where they are relevant (vs a list of 1-10 items), with the added benefit of being able to define custom keyboard shortcuts + being able to install/remove each of them with whatever calculation I can come up with as ‘install when’ condition.
Interesting idea. The Scripts menu is one of the FMP UI features that I really needs an upgrade.
The first thing is that we should be able to toggle it on/off completely from the Scripts dialog. If we don’t want to present scripts, there’s no need for the menu item to be there. And as we already have custom menus, the toggle would really be a UI shortcut that saves us having to define a custom menu set.
The next thing is that we should be able to control the display order, separators and folder nesting in the Script menu in a completely separate dialog from the one we use currently. The existing script dialog allows us as developer to arrange our scripts into sensible groups. The grouping that we set up in the back end for development reflects our needs - not the user’s needs. If we are going to expose scripts in the Scripts menu, that menu needs to be arranged for the users. The one dialog cannot do both jobs.
The only solution that I’ve found for this problem is to create a folder which stores scripts which are named for Users. Each of these scripts is simply a wrapper that calls “Perform Script” and passes the parameters on. It’s not too much effort but I consider it to be a nasty hack that requires a lot of maintenance.
same here. Users don’t get access to the “Scripts” menu. I have a Logo on top/left of every layout with a script that
If [ Abs(Get(SystemPlatform)) = 2 ] // in order to deal with the FM SingleDeviceInterface with PC
Show/Hide Menubar [ Lock: Off ; Toggle ]
Adjust Window [ Resize to Fit ]
End If
If [ Get(AccountPrivilegeSetName) = “[Full Access]” ]
Install Menu Set [ “[Standard FileMaker Menus]” ; Use as file default: Off ] // the developers Privileges
Show/Hide Toolbars [ Show ]
End If
If I want the users to have access to the layouts menu, I'll do something similar: create blank layouts named the way they expect, each with a script trigger that redirects where it needs to (other layout, report, ...)
Good point about context. All Scripts that are run from the Scripts Menu should run from any context. Get ( LayoutTableName ) is very helpful with that.
Actually I leave it for both.
It hamstrings its usefulness if, as a developer, I can only re-login as a user and then to get back to developer mode I have to close the whole file and reopen.
I suppose you could conditionally install it just for your developer-only test accounts for each privilege, but I’m not sure what the risk is by leaving it.
A user who is making multiple attempts to log in can do so more easily. However, the same user could close and reopen the file continuously - less convenient but the same result - so I don’t think that you are changing the risk.
But your capture is not from the native script menu. So you are using a custom menu. You choose to have shortcuts mapped from 0-9. It’s not imposed on you by the menu and if you had fewer items and someone added a script, it would not risk being displayed in this menu. That’s basically why I like custom menus when compared with the native scripts menu.
