This feature adds the power of custom scripting to the PDF tools. If the GUI tools do not provide the exact functionality that is required, a custom tool can be created for this purpose.
The functionality is generic enough that the scripts don't need to be specific to the processing/management of PDFs, so it's also an easy way to run custom scripts for any other file type directly from the shell files context menu.

Because it uses the Active Scripting technology, the scripting language can be any, or a mix, of the active language interpreters, called engines, installed in the system, with JScript and VBScript ready available in any Windows default setup.

It also provides compatibility with the Windows Script Host object model with a root WScript named object, so it's ready to run many of already available WSH compatible scripts.

The PDF-ShellTools manager is the place to create, edit and configure our scripts. The functionality is related to the context menu, so its options panel will appear when the Context Menu Tools item is the one selected in the manager settings list of provided shell extensions.

Some sample scripts are available, as shown in the above screenshot, and are the right place to start learning how all of this works. These samples are also defined by default to show in the context menu, so its respective menu item will appear in the shell context menu for the file types they are design to.

In the scripts configuration panel there are options to create a new script and edit or run the ones already available. The run option just exists here for practical reasons. The right place to run the scripts is from the shell context menu, and the option "show in the context menu", also linked to the checkboxes at right of each script name, define if the script will be available from the shell context menu.

The "file extensions" edit box is used to specify what file types will make the script respective menu item visible. Should be empty if we want the script invoke item to show in the context menu of any file type, or a list of the form .ext1.ext2.ext3... (e.g..pdf.doc.xls), if it should show only for specific file types.

The icon button opens an image selection dialog from where we can choose an image to use as icon of the item. Items without an icon will show only the script name text in the context menu.

When a script is executing it has available an output window to where text, and other script activity, can be displayed.

This output window dialog is also useful to stop the running script, if by any reason we need to stop it. But some scripts may not need this interactivity, so the "hide output window" option controls if this window will be visible when the script runs.

The "new" and "edit" buttons start the scripts editor, from where we can create, edit, run and debug our scripts.

Tip: This editor can also be started directly from the shell context menu, if a My Scripts script menu item is clicked while the Ctrl keyboard key is down. Very useful to debug the script with a given set of files.

This is a full featured editor and debugger, with syntax highlighting, code formatting, search, replace and undo/redo functionalities. The debugger has console interactivity, variables and locals watch, call stack list, breakpoints, and stepped execution. The debugger depends on some DLLs that may not be installed in our systems. An easy way to get these is by installing the ancient, and free, Microsoft Script Debugger.

Creating a new script starts by giving it a meaningful name, that can be renamed at any time. This is the text that will show later in its respective invoke context menu item.

From the coding languages selector, that list the automation languages installed in the system, we choose the language of the script.

The script can also access code stored in the scripts library, and for that there is only the need to check the libraries we want to use from the includes <> button. This method can be used also to develop scripts in more than one language, as the included scripts can be coded in different languages.

The code syntax is specific to the chosen script language and this site is a good start for JScript and VBScript, and Active Scripting in general.

To access the internal functionality provided by the tools, mainly specific to the processing of PDFs, we have the pdfe named root object, that is always available, without the need to create it, from any scripting language. This object provides the equivalent functionality of the WScript root object of the Windows Script Host object model. Its functionality and usage is explained in detail in the My Scripts API topic.

Using the API from an external host

The My Scripts API objects can be registered in the Windows system as COM/ActiveX objects, in order to use the API from an external host such as the Windows Script Host, MS Office tools or any other technology that can instantiate COM/ActiveX objects.
This registration is not done automatically by the installer and must be made manually from the manager My Scripts options panel (top of this page screenshot), button "Register". This process can also be automated by calling the manager, UAC elevated, passing the -regserver or -unregserver parameters to register or unregister, respectively (e.g. Manager.exe -regserver).

The servername.typename of the pdfe root object will be MyScripts.PDFEObject, so it can be instantiated by the usual, e.g. jscript, code: var pdfe = new ActiveXObject("MyScripts.PDFEObject");

Command line interface

Function name:	RunScript
Options:	[] means optional parameter
ScriptName=	- The name of the script to run
[-s]	- Silent mode. Run without showing the interface (only available for licensed users)
[fileslist]	- List of files to process with the script. Separate multiple files using the semicolon ";" char. Must be the last parameter
Example: "c:\Program Files\PDF-ShellTools\PDFShellTools.exe" RunScript "ScriptName=My Script 1" -s c:\PDFs\*.PDF