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.

This entry was posted in Acrobat, mac, PDF, Programming and tagged , , , , , , . Bookmark the permalink.

2 Responses to Is Your Acrobat Plug-in Still Using ADM?

  1. Vito says:

    Hello,

    i try to build the Adobe sample plugin wxPlugin in Visual studio community 2019

    I got an error, and the log doesnt help me at all ! Very boring

    1>Génération de code en cours…
    1>PIMain.c
    1>wxPlugin.cpp
    1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\include\xmemory(67,24): error C2131: l’expression n’a pas été évaluée en constante

    “error C2131: expression did not evaluate to a constant in VC 2015”

    => i dont find any Const not initialized in the project …
    can you help me ?

    thanks a lot

  2. Karl Heinz Kremer says:

    Vito, VS 2019 is not a supported build environment for Acrobat plug-ins, so we don’t know if the error you are seeing is due to that, or because there is a problem with your code. I have not worked with wxWidgets in quite some time, so unfortunately, I am a bit out of the loop. This blog post is from 2010, and I have forgotten a lot since then 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *