So many great resources here. Thanks to everyone for contributing and compiling these lists and even testing them in different versions.
On the topic of menu commands, my biggest gripe has always been the naming convention of the commands. In many cases, the argument required for app.executeMenuCommand() is cryptic, nonsensical, or not at all descriptive of what the command does. Additionally, the variable naming convention makes it very difficult to remember how to format the argument for the command you need. And incorrectly formatting your menu command argument brings about the dreaded MRAP/PARM.
Would there be any interest in, or do you think you might use some kind of framework for app.executeMenuCommand() allowing the freedom to effectively namespace "app.executeMenuCommand" with a custom function name (personally, id choose emc("commandName"); but any user could choose whatever function name they want. Then within the function, the custom arguments are assigned to the appropriate argument for executeMenuCommand(). Errant arguments could also be handled more gracefully and with more useful info than a generic mrap.
This also gives freedom to the user to customize their command/argument pairs to best suit their workflow. As an example, to select all same fill colors, the default argument is "Find Fill Color menu item" in a frustrating variable letter case scheme.. I'd like to call that command with emc("sameFill"); so in my emc() function, i'd assign "sameFill" to "Find Fill Color menu item", then input the appropriate argument into executeMenuCommand();
It would also be possible to include custom logic before/after the actual menu command for certain commands. As an example, the live pathfinder effects often need to be expanded. But not always. emc() could accept another argument for enabling or disabling the paired functionality, or even just passing it in as one of the parameters. perhaps an object literal for feeding custom params to different functions.
You could also bind multiple menu commands together for common tasks, all while keeping your main code nice and tidy (a big priority of mine after many years of writing disgusting spaghetti code) with menu command arguments that make sense to YOU and are customizable for your own workflow.
If optimization is desired.. I.E, not including a giant function with 500+ commands to every script just so you can use one or two.. The commands could be split into smaller chunks by category like "File", "Edit", etc. Or even compact custom sets for production that only include the commands your code actually uses.
What do you guys think? I know extendscript/scripting-as-we-know-it is dying anyway and transitioning to UXP.. But I think this would be a pretty straightforward build that could still be useful in the interim.
3 Correct answers
24
Replies
AdChoices