CNS Menu allows you to place hierarchal menus anywhere on a FileMaker layout. When a menu item is chosen, the script of your choice in the database of your choice is performed. Menus can have any number of sub menus and can be displayed with a variety of styles and bullet marks. Creating menus with CNS Menu is as easy as using as handing the plug-in a return delimited string of menu items to display. Your menu items can have a display name, and a value that can be used in your scripts, so the end user can see useful information such as a customer name while the value can be a Customer ID number.
CNS Menu ships with the "CNS Menu.fp7" example database which includes 15 examples demonstrating ways to use and understand the CNS Menu more...
Yes, that would work. A bit pricey, though, my needs -- 2 computers=two licenses=$130. Oh, well. I just may have to resort to custom menus. Or keep the buttons.
Why not have one global field and attach it to each button. Then have it use a different Value List for each button occurance. That is how we design our 'standing navigation menus' on each layout. The global field has only one script attached to it, so it is the same button duplicated, with just the value list changed.
I had hoped to avoid "fields" altogether (in a manner similar to 4D), but lacking that capability, one global field for all such instances may be acceptable. I'll work on that idea for a bit. Not sure I like the fact that the popup will look the same as the several other popup fields of real data that I already have on the layout. May need to change the look (color?) of the global field popups.
Thanks for the idea. Any other hints for designing/coding?
Note that a field with global storage can be accessed from any layout and via any script in your database file. I often add a globals table that stores nothing but global fields in order to keep them out of other tables and to make them easier to keep track of. The one exception is that global fields used in a relationship have to be defined in a specific table in order for the relationship to work correctly.
Note also that global fields are local to the current user if you host the database over a network. (Changes made to a global field by one user are not visible to other users and changes made to a global field will not be retained when a client user closes the file.). This can make global field very useful in situations such as that used here as it can keep different users from "colliding" when they both select different fields from the global field's value list at the same time.
Good idea, that, a globals table with only global fields. I've created a new table with a single field (for now), then created a popup control on my invoices layout. Changed the coloring to match the button coloring (not sure I'll keep it that way), assigned a value list to it, and it works. Onward to the script....
My original idea was to have each of the values in value list be the name of the associated script. I had thought that I'd be able to create a control script with a "Perform script " statement that could accept the contents of that global field or a variable as a parameter. Alas, that didn't work -- "Perform script" only accepts a single assigned script name.
I then figured that I'd create a long "case of" procedure that would test each case against the contents of the global field and perform the associated script. But FileMaker Pro 12 does not appear to have a "case of" in its scripting language. Got "if" statements, but fo the number of scripts I considering, that would create some awkward code, to put it mildly.
How can I perform a script based on a selection from a popup of script names? Is it even possible?
I can't share your reluctance to create one field, but, anyway...
To create the setup you have above, assuming you mean each header 'Nohinsho', 'Seikyusho' and 'Envelope' to have a pop-up menu with 4, 4, and 2 options respectively, then I would:
- Create 10 scripts:
- Create one global field, 'PrintChoice', say
- Create 3 value lists
- Create one more script, 'Do PrintChoice':
If [PrintChoice = "Preview Nohin" ]
Perform Script [Preview Nohin]
If [PrintChoice = "Print Nohin" ]
Perform Script [Print Nohin]
If [PrintChoice = "Email Nohin" ]
Perform Script [E-mail Nohin]
If [PrintChoice = "Print Envelope" ]
Perform Script [Print Envelope]
- Attach that last script to the global field as a script trigger. Duplicate it twice more
- Attach each value list to each of the 3 fields.
Yep, that's pretty much what I came up with, although my "Do PrintChoice" script didn't have the "Halt Script" commands. But adding them pretty much reproduces the "Case of" command I was looking for. Cool! And thanks!
Once I had this working, I saw another use for this "global field" popup technique: a popup for fast navigation between layouts. So I overcame my reluctance to create non-data fields and created a second field to handle that usage. Works great, and unclutters the layout even more. (My reluctance comes from my years writing 4D databases; 4D doesn't (didn't) allow fields and tables to be deleted, so every field/table was a permanent commitment and had to be carefully thought through.)
Got a bit of a problem though. When a choice is made from the Layouts list, the choice goes into the field, so I turned it into a title at the top of the layout, replacing the straight-text title I was using. Increased the font size, removed the fill from the background, etc. Works great. But in the case of the "PrintChoice" popup, I don't want the choice text to remain. I tried adding statements to insert other text ("Print/Email/Save"), but the popup text never took it. I tried the "Insert text", "Set field", and "Replace text", but nothing worked. Any ideas?
You could replace the halt script step with an 'Else If' construction, but I think sometimes clear and simple is better than clever-clever. I understand your point about 4D - although in the case of global fields you could re-assign them a different duty if you wanted to 'back-track'.
For your tidying-up part, the last two steps of the 'Do Print Choice' script are Set Field [global Field ; "" ] and Commit Record. That makes the field 'vanish'. I usually just put the field with its pop-up directly over the button, so when you click on the button the list pops up, and when you select a value the list and field disappear.
You could replace the halt script step with an 'Else If' construction, but I think sometimes clear and simple is better than clever-clever.
Absoposilutely agree. And your tips solved the clean-up issue. Thanks!