For a few years now Adobe has been telling 3rd party developers that the ADM (Adobe Dialog Manager) will be discontinued, and that existing plug-ins may have to be ported to something else. If I remember correctly, this started with Acrobat 7 or 8, but back then it was a soft threat – everything still worked, and there wasn’t much incentive to start porting plug-ins. However, with the release of the Acrobat 9 SDK the ADM related header files were gone, but ADM based plug-ins were still working (at least some of them).

The removal of the header files does send a strong signal, but what was an even stronger signal for me was that one of the ADM based plug-in I was working on was no longer working correctly on some versions of Windows.

As far as Adobe is concerned, ADM is no longer supported – that means there won’t be any bug fixes for it, but the plug-in has to work with Acrobat 9 on any Windows system that’s supported by Acrobat 9. So, what is a developer to do in such a situation?

Adobe does not give us much guidance in what to chose as a replacement for ADM. The most obvious choice is to stick with the native UI framework that comes with the operating system, but the advantage of ADM was that one could write UI code that would run in both Windows and Mac plug-ins. One of the sample plug-ins – wxPlugin – that comes with the Acrobat SDK is based on wxWidgets. To me that was a pretty strong hint that wxWidgets would be a good choice…

However, even though the Mac version of the SDK does come with the wxPlugin code and even contains a XCode project file, it does not compile. After some work, trying to come up with a combination of wxWidget configuration options and wxPlugin project settings, I was able to create an Acrobat plug-in that worked.

In order to “fix” the Mac’s version of the wxPlugin I first had to compile wxWidgets. Use the following configure command line to create the static wxWidget libraries that can be linked with the project:

configure CC=gcc-4.0 CXX=g++-4.0 LD=g++-4.0 --enable-universal_binary \
--disable-shared --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk \
--with-mmacosx-version-min=10.4 --enable-debug

Just install the libraries and include files according to the instructions provided by Adobe.

A closer inspection of the plug-in code then revealed that the part that actually did anything was commented out for the Mac with #ifndef MAC_PLATFORM statements, so I removed those and the last thing to do was to remove the reference to the libexpat library – it is provided by the operating system and does not have to be provided by wxWidgets.

With a working environment on the Mac, wxWidgets is a viable alternative for ADM for either new Acrobat plug-ins, or existing plug-ins that need to be modified to make them compatible with the current version of Acrobat.

If your Acrobat plug-ins are still using ADM, now would be a good time to think about what to do about that… If you need any help, let me know.

Acrobat’s JavaScript is a great tool to extend the application, or to automate reoccurring tasks. There are several ways a JavaScript can be added to the application or a document (e.g. folder level scripts, validation scripts, event handling scripts, …), but regardless of how a script is written, chances are that the developer wants to test parts of the script in Acrobat’s Javascript console. This console window can be shown by either using the “Advanced>Document Processing>JavaScript Debugger…” menu item or Ctrl-J on Windows or Cmd-J on a Mac:

After the console or debugger window comes up, the user can then enter Javascript and execute it…

… that is, as long as a full keyboard with a numeric keypad is used. In Adobe’s documentation, we find the following instructions to execute Javascript typed into the console window:

The JavaScript console allows you to evaluate single or multiple lines of code. There are three ways to evaluate JavaScript code while using the interactive console:

• To evaluate a portion of a line of code, highlight the portion and press either the Enter key on the numeric keypad or press Ctrl + Enter.
• To evaluate a single line of code, make sure the cursor is positioned on that line and press either the Enter key on the numeric keypad or press Ctrl + Enter.
• To evaluate multiple lines of code, highlight those lines and press either the Enter key on the numeric keypad or press Ctrl + Enter.

That works fine as long as you have access to the numeric keypad, but on a MacBook or a MacBook Pro without that keypad. No key combination involving fn, ctrl, cmd or option with the Return or Enter key will result in the Javascript getting executed.

The virtual keyboard to the rescue: Mac OS comes with a handy keyboard viewer that allows us to send the correct key code to the application. To bring up the keyboard viewer, bring up the Mac OS System Preferences first and select the “Keyboard” category:

Make sure that the option “Show Keyboard & Character Viewer in menu bar” is selected. Once this is done, you can access the keyboard viewer from the menu bar:

Now comes the tricky part: Write some Javascript in the console window and place the cursor on the line you want to execute or select the snippet of the Javascript that should be executed. In the following example I’m using code from Adobe’s Javascript API documentation:

  var menuItems = app.listMenuItems()
  for( var i in menuItems)
    console.println(menuItems[i] + "\n")

With the console prepped, bring up the keyboard viewer and start pushing keys – real keys that is: Hold down the “fn” and the “control” key, then move the mouse pointer to the “Enter” key on the keyboard viewer and click it…

… and voila, the script gets executed:

This is not the most straight forward method, but at least it’s possible to use the Javascript console to execute code when using a MacBook.