23 Apr 2010

Is Your Acrobat Plug-in Still Using ADM?

Posted by khk

Update:

Please visit the same post on my business site. The comments are closed here, so if you want to comment, you have to head over to http://khkonsulting.com/2010/04/is-your-acrobat-plug-in-still-using-adm/

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.

Comments are closed.