Real productive modern applications have contextual menus. Therefore filemaker should have them also, fully accessible to the developper (not just the ones filemaker has built-in).
Filemaker application will look much more polished, and professionnal
CM are great for productivity, they also help the user to discover the feature (once they know they can use CM), as it allows the dev to give the user the feature he needs according to the exact context. For instance, I've a list view with prices, product titles. On the pice CM, then I could have a menu allowing me to decrease the price by 10%, sort the list by price, compute average prices etc. But on the title I could have the sorts but also the possibility to copy. Right now, this needs to be on different buttons in an header bar. That's a waste of space and it's confusing.
Needed Features :
- They need to be applicable on any Filemaker object. Provided those object have a unique identifier that the dev can access
- For fields, a different menu (or the same) could be applied according Field entry browse or find mode. Yes contrary to current built-in FMP Contextual menu (CM), dev should be able to allow a CM to apply (and access) non editable fields.
- They need to be hierarchical
- The FM built-in CM should be fully overridable (even in table view)
- The CM contents should be dynamically generated by a calc
- Their items should trigger scripts* or just single step line (just like buttons)
- The contents of the Filemaker object they're attached to must be accessible in a generic way (clicked_item_contents, so the CM can be reused everywhere)
- They need to work anywhere, yes I mean even in portals & table views
- It should be possible for the developper to manage them in standard filemaker table, via layout and object item internal_IDS, and then the dev could put the same calc on all items in any layout, that would fetch the correct one
- Optionally a small widget should indicate the presence of the CM to the user
- The text style of the items should be settable
- Their should be dividers
* This reinforce the necessity to have a perform script by script ID (and filenames).