Interesting question. I've never had a need to do this but I was curious if it was possible. You can specify a script parameter for a menu item in a custom menu. Here is what I did:
- Go to Tools > Custom Menus > Manage Custom Menus…
- The Manage Custom Menus dialog will appear.
- Double-click the menu set you want to edit.
- The Edit Custom Menu Set dialog will appear.
- Double-click the menu you want to edit.
- The Edit Custom Menu dialog will appear.
- Click on the menu item you want to edit (left) to populate the editable options (right).
- Check the box “Action” and specify a script.
- The Specify Script Step dialog will appear with the Perform Script step added. Click on the text “<unknown>” (or your script name).
- The Specify Script dialog will appear, with a list of available scripts. In the bottom of this dialog you can specify an optional script parameter.
Interesting. This exists in FMP13, but not FMP14. Unfortunately, even with 13 I can't dynamically pass a script parameter based on the layout the user is on, and that's what I'm trying to do.
I find it easier to pass a "switch" to a script, rather than configuring the logic in the parameter calculation box.
Put the name of the script you want to run in textbox on the layout, set it to hidden, and name it "script.name"
At the start of your script, grab the value by
Set Variable[ $script.name ; GetLayoutObjectAttribute ( "script.name" ; "content ) ]
Then use $script.name in an If/Else If tree to run the correct script.
Once this is in place, it doesn't matter if you're calling the script from a button or custom menu, or Script Workspace menu. It just runs.
How is this easier and what's the advantage, in your view?
Genuinely curious. I've been doing a lot with GetLayoutObjectAttribute lately, and finding lots of great ways to abstract logic and get more out of scripts, layout objects, etc with less work. At first blush, though, this seems more effort/steps than just using the standard method. Can you elaborate?
I'm not sure what the "standard" method is. I use parameters for record-level events. But for layouts, I use (what I call) switches which allows me to keep track of things at the layout level with minimum fuss. Switches are simply named textboxes.
Before, I'd have to use layout name, but that wasn't great, because my layout names are often user-facing and if I changed a name, my script would break. Also, I couldn't assign an action to a group of layouts (like print orientation).
Then I tried parameters, which may be "standard". But I had to worry about context (so I had to add logic depending on if I called something from a button or a custom menu or even another script) and ease of use, changing a custom menu parameter involves going deep into that section, etc.
For a while, I tied logic to layouts using variables in conditional formatting calcs, but again, that was a couple dialogs deep. And I don't like "cluttering" up the variable space, worrying about namespace conflicts, and numerous refresh issues.
Once I stumbled on the GetLayoutObjectAttribute() answer, it just felt perfect. I can have one place where I modify a bunch of aspects of how scripts (and other things like custom menus) handle based on the layout. Now, I put all my "Switches" on a hidden, offscreen pop over, so it's only accessible in layout mode. I use a lot of different switches, most of them either for those things FileMaker can't handle "programmatically" like Sort or Print Setup, and/or for custom menus (e.g. showing the "New Record" command) or both.
Some of my Switch names (the name of the textbox / sample textbox content ):
allow.new.record / 1
allow.delete.record / 0
print.orientation / landscape
print.number / all
default.find / customers
default.sort / customers
I have a simple custom function, Switch ( name ) = Get ( LayoutObjectAttribute ( name ; "content ) )
My Print script may look like this:
If [ Switch ( print.orientation ) = "landscape" ]
Print Setup [ Landscape ]
Else If [ Switch ( print.orientation ) = "portrait"
Print Setup [ Portrait ]
Print Setup 
Interesting! Thank you for sharing.
Could you elaborate on your custom functions and how this all works. Sounds interesting.
You could use an onLayoutEnter script trigger to set a $$globalVariable for that layout. If you assign one of these to each layout from which the custom menu item might be called, you can then program the custom script to use the value of that variable when it executes, and each layout will take the user to its own destination.
Use the exact same $$variable NAME for all layouts, just change its value. This avoids having to set the variable value right at the time it is needed; just having it lying in wait from the layout trigger-script.
David, this sounds really interesting. Would it be possible for you to post a small file as an example? I'm not quite sure what you mean by a named textbox.
Very intriguing way to avoid the IFTHEN statements. I'm looking forward to giving this a try.
That was actually going to be my suggestion right there.
Won't this break in a multi-window situation?
Yes, I would go with the previous suggestion of adding the hidden item.value to each layout and triggering the parameter based on that object name.