[javascript] add menu item to ribbon UI SOLVED

[Mathew]

The app.addMenuItem() and app.addSubMenu() functions add javascripts to menus in the classic UI but there's no equivalent for the ribbon UI. The only place we can add anything on the ribbon is to the Addon Tools, as far as I can tell.

Could PDF-XChange add a way to do this? I have a lot of small scripts I use within the Editor, and the Addon tools are getting very congested, plus the tools would fit better into other contexts (such as Comment, Organize, Bookmarks, etc).

[Mathew]

Possible approach: An additional parameter -- such as "cParentRUI" and "nPosRUI"-- that could be ignored by applications that don't support it. If both parameters were supplied, then both UIs would know where to put the menu item if the UI is changed.

[Daniel - PDF-XChange]

Hello, Mathew

Sorry for the long delay in a reply here, The dev team have agreed to have a think about this. But that have also informed me that it is, unfortunately, a low priority item at this time. Nonetheless I have made a formal ticket for you on this.

RT#6655: FR: JS add-tool to other ribbon tabs.

Kind regards,

[Mathew]

Thank you

[Daniel - PDF-XChange]

[Mathew]

The more I bump into this one, the more I think Adobe's old approach to this is in need of an update. They came up with it before anyone had the ribbon, and it also doesn't allow for things like assigning shortcuts, or letting people rearrange their menus the way that suits them.

I know this is a low priority item, but it will add to the overall usability of the software.

When you do start looking at this, I'm thinking that javascript should just be suggesting a location, but that really what javascript would do is add a tool with a default location, but that can be moved or assigned a keyboard shortcut in the same way anything else is changed in Customize...

[Daniel - PDF-XChange]

Hello, Mathew

The difficulty with such actions is that the JS is not "kept in place" or recorded between sessions, it needs to be reloaded each time the application starts. This requirement of reloading the Js files themselves inherently prevents storing any "external" customizations beyond what is present in the JS itself for button customization/naming.
While we may be able to expand placement (as the ticket requests), so you can specify that a tool should appear on, for example, the "home" tab; Other tasks, like allowing manual movement, or hotkey assignment, would not work very well. The moment the software closes, that "instance" of the tool is destroyed, and so subsequent re-opening of the editor would move it back to its initial "home" and the hotkeys would need to be reassigned manually.

Trying to retain these hotkeys and button positions, with something as volatile as the presence of a named JS file that can be removed, replaced, duplicated, etc. at any time would be... "tricky" at best.

Kind regards,

[Mathew]

Hi Daniel,

I don't know what's going on "behind the scenes", but here are my thoughts on this:

• The UI currently allows one to change between Ribbon, Tablet or Classic UI and this happens after all the menus have been shown, so at that time, it is known which javascript tools are loaded.
• When javascript adds a tool it has to include a cName which according to the api is

  "A unique language-independent identifier for the button. The language-independent name is used to access the button for other methods (for example, removeToolButton). Note: The value of cName must be unique."

  Thus there is a way to map this menu item to an internal list of menu item locations and keyboard shortcuts.
• Currently the only properties that are not optional are cName, oIcon (or cLabel), and cExec. Thus the application needs to come up with a place to put the button already, and the provided location is only there as a way for the script to override a default location.
• When the application handles app.addToolButton(): If it has that cName stored, it could ignore the location given in the script and put it where the saved location is; if the cName isn't stored, then js has provided a default location.

I think the methods .addMenuItem() .addSubMenu() .addToolButton() are all out of alignment with how the UI is: In my mind there isn't a difference between them fundamentally. They are just adding a tool, and within the parameters it should be providing default location, icon, etc.

[Daniel - PDF-XChange]

Hello, Mathew

Unfortunately it is precisely because of what happens "behind the scenes" that it is currently not possible to allow lasting customization between application sessions, so they are not enabled for customization at all, to prevent the chance of having that work ignored/reverted every time you re-launch the software.

As before, we should be able to expand the possible locations so that you can place these tools on any Ribbon tab or Classic Toolbar Via the JS, but at this point in time, customizing hotkeys and repositioning these tools after runtime is not possible.

Kind regards,

[Mathew]

Thanks for getting back about it. I still think PDFX-Change is second to none, and I'm continually blown away by the level of customer support. You're all fantastic. Keep up the good work. You all are very much appreciated.

[Daniel - PDF-XChange]

[Mathew]

**SOLVED!** and in a big way in build 388. All the new options for app.addMenuItem(), app.addSubMenu() and app.addToolButton() make it possible to put scripts in logical places in PDFX-Change. The sample scripts and information is here:
https://files.tracker-software.support/ ... yjtxeT5fGR

I extracted the notes and formatted them similarly to the Acrobat Javascript SDK - I find it easier to reference a pdf of the SDK than the web or a text file. Here it is:

PXCE menu-toolbar methods.pdf

The PDFX-Change improvements to the app methods

(183.65 KiB) Downloaded 74 times

After playing around with it a bit, I realized that .addMenutItem() in the RibbonUI is really a duplicate of .addToolButton() but:

• .addToolButton() has the cTooltext parameter which is really useful to add a bit of information, or usage, or a longer name. In the ribbonUI, all the built-in "menu items" are actually tool buttons, and they have this property;
• .addMenuItem() can be placed in any menu or toolbar in the ribbonUI, but not .addToolButton(): there's a limit to where can be placed for some reason.

Besides that now scripts can be put in useful locations in the ribbonUI, I really like the oIcon addition to .addMenuItem and it shows in both the ribbon and the classic UI.

A few "examples" are given for cIconID, but I don't know where a complete listing of possible values are?

My only request would be either to add cTooltext as a parameter to .addMenuItem or allow .addToolButton to be placed anywhere in the ribbon UI.

[Stefan - PDF-XChange]

Hello Mathew,

Thanks for the post and happy to hear you like the changes so far! I will ask our devs working on the JS to take a look at your question and request and will post an update here as soon as I can!

Kind regards,
Stefan