Overview
Developing within FileMaker is unlike working within an Integrated development environment. In order to facilitate developer features beyond those provided by FileMaker itself, it's helpful to add specific developer features to aid in the development process.
Example of a Developer menu
The following screen shot presents a Developer menu which only appears when the file is opened with developmental access (typically by using the Developer custom function).
Implementation
While the Standards.fp7 file does include the Developer menu set and menu, it is documented here for reference.
The process of adding a Developer menu is very straight forward. Follow these steps.
1) Rename the secondary menu created by FileMaker from Custom Menu Set 1 to Developer. If you've already renamed this menu and deleted items, then you'll have to start from scratch or duplicate any other menu as a starting point.
2) Create a new Custom Menu named Developer and add this to the Custom Menu Set named Developer (note: A Custom Menu Set and Custom Menu are two different things).
3) Make sure to add the Developer custom function to your solution. This is used to limit access to running developer related scripts.
4) Create a dedicated Developer Startup script which is called via a Perform Script step within the actual Startup script set in the File options. Provided the logged-in account is a Developer account, the Developer menu should be installed.
Relationship Graph Warning
As of FileMaker 11, there is an issue (bug) with the alignment features for Table Occurrences when attempting to align using the alignment icons at the bottom of the graph. These items will be grayed out if the default [Standard FileMaker Menus] is not currently set. To regain these alignment features in the Graph, you will need to set the current menu set to the standard menus temporarily and then back to the Developer menu set.
5) Use one single script as a dispatcher for all developer related actions (menu items within the Developer menu). This simplifies the process of managing individual menus. Passing a named parameter of $key tells the dispatcher script which sub-script to run.
6) Add as many relevant Developer related menu items to this menu. The following screen shot shows two common developer actions of saving a backup (only works on a locally developed file) and re-login. Make note of the Perform Script action for the menu where making a new menu item is simply a matter of clicking the Duplicate button and changing the inbound parameter of $key.
10 Comments
Anonymous
I love the use of a developer menu! We use one in our framework solution and it's hugely useful, and you've given me some good ideas on new items that can go onto it thanks!
Something you might like to check out is This Article that I did a while back on hiding menu elements. Using this technique for a developer menu means you can still retain layout/file default custom menus which are useful to see when developing and debugging a solution, and the developer menu can be added into these menus for use. Sometimes when using a specific developer menu set instead of the original menu set, you may miss some bugs that a regular user will see when their menu set is used.
FMWeetbicks / Daniel
(btw, I did try to sign up for an account but got an error saying its not permitted, which is why this has come up as anonymous).
Matt Petrowsky
Daniel, due to the limited number of wiki accounts (this is a semi-opensource wiki) we've got limited access and it's not fully open. However, anyone who is seriously interested in getting involved in our objectives here will certainly get an account. Here's more information about Getting Involved - I'd love to have you involved if what we are doing here make sense within your own development practices.
Anonymous
Great imeplementation of an idea probably many developers had but most of them were too lazy to actually implement it :-)
BTW, if you're using 24U SimpleDialog Plug-In, very useful item for this menu is Close All Progress Dialogs evaluating this calc:
SDialog_ProgressDialog("close"; "all")HOnza
Anonymous
I like to have a Show Status Area item in the Developer menu. It's useful for when the status area is locked.
- Dan Smith
Anonymous
oops, I guess it does show that in the screenshot on this page. I was only looking in the Standards.fp7 file when I made that comment.
- Dan
Anonymous
"CMD /S /C "
/ quote all the commands
& "\""
// compress file
& "\"%ProgramFiles%.\7-Zip\7z.exe\" a \"" & $pathCompressed & "\" \"" & $path & "\""
// delete fp7 file, if compression worked
& " && DEL \"" & $path & "\""
& "\""
I love the "Backup File" menu item. That was a great idea!
I added steps to compress the backup, and delete the .fp7 file after the copy is saved. For Windows using the 7-zip command line utility, I put this in a "Send Event" script step:
Anonymous
The relationship graph warning above is only relevant when the file is in Browse mode. If it's in Layout mode when opening Manage Database, the controls are available when a custom menu is loaded.
Jeremy Bante
Now that FileMaker 12 gives us the ability to conditionally show or hide menus and menu items based on a calculation, I've found it easier for myself to just include the Developer menu in all custom menu sets, but only when the logged-in user is a developer (determined using the Developer custom function).
Matt Petrowsky
Nice one.
I'll have to add the test for the menu into the Standards.fmp12 file. Given the Developer custom function, by default, uses the privilege set or an explicit account name, or the "developer" extended privilege, we may need to look into an enhancement that would allow the Developer menu to persist within other application menus for the purpose of including testing/developer functionality.
The best I can think of right now would be to create some type of hash based on first startup and the priv set of [Full Access] or other developer specific criteria being used. The hash (within a $$DEVELOPER global) would then be used when switching to other accounts/priv sets for the purpose of testing - yet the Developer menu would persist.
Seem reasonable/possible?
Jeremy Bante
Makes sense to me. But why would we want $$~DEVELOPER to be hash instead of a simple boolean flag? If an intruder invests the effort to set the $$~DEVELOPER variable to reveal the Developer menu for themselves even if they otherwise shouldn't be able to, I expect any truly sensitive actions are handled by FileMaker's native account security anyway. It's their problem if continuing to see the Developer menu is somehow inconvenient — serves them right. What if the Developer function set the $$~DEVELOPER flag itself the first time it gets a positive result, and then uses the flag to assume the user is a developer for the rest of the session?