Bad choice of words for "somewhat dangerous" in that we are handing off functionality in the form of scripts to the user. With power comes responsibility, so from our perspective, the scripts are yours and when they don't work, you own the problem. Our QA effort would be to validate that the before and after commands run for each supported command, but you own the rest.

As for passing the result of the command that is run, if it fails all sorts of dialog's can pop up. In this case, XPP would NOT run the "after" script, since the command is not valid. Can you envision scenarios where you would want a "after" script to run, when the XPP command fails?

Unfortunately the option you mention as somewhat dangerous is the one that would provide the before / after steps Toppan would most benefit from. In this scenario, would XPP be returning success / fail messages or codes to the "after" script (depending on the command run)?

The before / after functionality and the ability to selectively disable certain functions in the interface (#3), would allow us customize certain aspects of the installation and help point our users to the correct functionality.

I should mention on point #4, that certain commands are run asynchronously and therefore cannot have an "after". These include:  Edit/View Division, Editing the Division or Job Ticket and Editing the Document Assembly spec.

More thoughts...

4. While it is somewhat dangerous, we are also looking at adding before/after PERL scripts to the menu commands for the Job/Division context menus. If the PERL script exists (in a folder to be named later), the script would run as ' menuid.pl before "Path" ' prior to the XPP command, and ' menuid.pl after "Path" ' after the command.

Provision would be made via script exit values, to cancel the XPP command altogether on the "before" or disable any XPP confirmation pop-ups on the "after".

For example, a 'setcap.pl before "/alljobz/CLS_x/GRP_y/JOB_z/DIV_div" ' would run if the user uses the "Set CAP baseline" menu . Once the XPP command has executed, the "setcap.pl" would run with an "after" and the same path to the Division.

Any comments? Would this help meet your requirements?

Given the current design of pathfinder, this does not seem doable. The menu system is pretty much locked down with no way to extrapolate into a user configuration file for describing the menu structure. However, there have been other requests pertaining to the organization/traversal of the menus. A couple of thoughts come to mind.

1. The context menus that pop up for Job/Div/Class/Style etc cannot have short-cuts  per se because they are "pop-ups"; i.e. they dont exist until the context menu is activated so you cannot do a short-cut to them.There are keyboard access keys built into all of the pop menus,  but they are really unavailable because you can't pop up the context menu with a keyboard command.

XPP 9.3 will support the Windows SHIFT F10 keyboard that will pop up the floating menu depending on what you are pointing at. From there, the underlined letter will trigger the action if you hit that letter on the keyboard. This is a form of short-cut that can save some time.

2. The Job/Div Tools could use some TLC. When a Job/Div is selected, the right mouse context (or now the SHIFT F10) will show the context menu. However, to use customer created "More Tools" programs, you have to select, Job (or Div) Tools, and then "More tools" and then the program to run from yet another sub-menu. Since there are only a couple of Job/Div tools under "Tools", the menus could be streamlined, if they are moved up to the top popup and the More Tools (and its list of programs as a sub-menu)  are also moved to the top. This will save mouse clicks and also feed in nicely to the SHIFT F10. The user could do SHIFT F10 T (for tools) and then a number or use the down arrow to select the appropriate program.

   For Job Tools, this would bring Exception Dictionary, Save Function Keys, Restore Function Keys and Set CAP Base up one level along with the "More tools" sub-menu.

   For Div Tools, this would bring Edit ASCII file, View ASCII file, Edit LOEP, and Set CAP Baseline up one level, along with the "More tools" sub-menu.

3. Some of the requests pertaining to configuring the menus is expressly targeted at preventing users from executing certain functions. This has the potential to be a useful feature if enough people have the requirement. I can envision a configuration file with a list of names of the different menus. Setting the name to "disable" would gray out the menu and not make it available. This could be some kind of global configuration with a way to override values on a per user basis. With the functionality, a user could be locked out of being able to run the font import, or any other menu item (including the pop-ups). You could also put the names of the Job/Div Tools program names under "More tools" into the configuration file(s) and prevent users from being able to run individual custom programs.