I’ve been using custom menus in FileMaker for some time, but there’s one area I haven’t been able to figure out how to customize.
I want the active year to auto-enter into a Year field whenever a user enters Find Mode. I was able to set this up fairly easily for the Find button.
However, I’m having trouble with the drop-down menu option in Find button. The “Create New Find” menu item seems to behave as if it has its own separate command, but I can’t find it in the custom menus.
My questions are:
Is this behavior something that can be changed through custom menus?
If so, where exactly is the command for “Create New Find” located?
You’re quite right, it’s perhaps one of the only menu that isn’t actually part of the overall menu set and doesn’t exist in the standard menus.
The only workaround I could offer is an onModeEnter trigger on the layout, set to only run in find mode, and have this run the custom script to set the year field as below.
Granted, it’s not as nice as a menu because it needs to be set up on every layout
FWIIW I never use visible custom menus or any menus, at least in the last couple decades. With mobile and web deployment so common, menus don’t make much sense and are far harder to limit/control customer behavior.
But I have seen some excellent work with custom menus - all in tools for power users and not your typical FM user.
I really should consider this as the nature next step. I have modified the behavior of just about all the native menus already. Might as well just replace them at this point.
Any suggestion or tips you have learned from your builds?
That’s a really broad topic with a huge variety of possible approaches. Personal preferences and customer capabilities ( and tolerance for unexpected results ) come to play as well.
from my perspective (disclaimer: strong personal bias - YMMV):
The only menu choice is “about”
The only menus modified are the close and quit options….i don’t allow users to use the operating systems close window options to exit any window. Doing so would, in many cases, circumvent the scripted actions codified in navigation. Instead these are captured, forcing a return to the splash screen where a quit button exists.
FINDS are either canned scripts for specific conditions, or opening a separate window with selective fields for find, followed by one of a few different techniques to deal with the fact that a found set is window specific…. to get the results back to the original window.
This also helps with the significant design issue regarding finds with fields from related tables. (A field from a child table shows the first record of the related table based on relational sort order, BUT a find against that same field ignores the relationship and searches all records of the child table not just the shown one there are a few ways around this - like de-normalizing the field using a field in the parent to pull the child content- but using a separate window allows presentation of selective fields which can often eliminate the issue altogether ).
the new FM25 command and script step that deals with record IDs codifies and simplifies one of the legacy approaches to this multi-window find issue.
Navigation is all scripted and controlled operational sequences.
Menus are all card windows with either multi-segment button bars or virtual lists using keypair to define cascading menu selections
Except for card windows, the “single pane of glass” window management approach is typically followed. This not only reduces the complexities of multi-window management, but allows Web Direct and FMGo operate within the same construct without changes.
I am not sure I am ready to control my users to that level just yet. But you have some interesting methods it sounds like. Thanks for sharing. I will definitely consider some of them.
I worked on a system where users used the layout list a the top to get to a different layout . When I asked their beloved consultant why they wey doing it this way, the answer was "it's there, we use it". .
We had that issue as well and I was really surprised. We ended up keeping the option but limiting the layouts to just a few that did not break anything.
User really do surprise you though. I am still not sure why users will start a search by using the drop down and “Create New Find” instead of just hitting the find button?
Just for fun, I'll add my approach: I always install custom menus, but generally all needed actions are scripted and available on the layouts (Navigation Header, Header, etc.). They have no access to the status bar, and menus are limited. Because of carefully designed layouts and scripting, my clients' users don't even access the FM menu at all, except for a couple (few?) across perhaps 3-4 organizations where a user opens a new window to compare two records. This is rare, but I added the New Window option for specific use-case in a laboratory.
The reason the limited menus are even installed is because in a few cases I have taught a few users to use Extend Found Set and Constrain Found Set, but in actual practice that's rarely used. Oh, Paste Text Only is often handy, but can be handled with an Auto-entry calc on such fields. I would say that ~90% of my users have never even opened the top menu bar.
My policy is to observe (and request users to tell us of) any action that is repeated (or wished for), so we can provide the UI and scripts to automate the action.
. When I asked their beloved consultant why they wey doing it this way, the answer was "it's there, we use it". 
.