Skip to main content
Thom Parker
Community Expert
Thom ParkerCommunity Expert
Community Expert
February 7, 2018
Answered

Plug-ins for extending the IAC interfaces

  • February 7, 2018
  • 1 reply
  • 709 views

The title of this question is a title I found in the SDK documentation. It's a very short section that includes this text:

You can extend the functionality of the IAC interfaces by writing plug-ins that use core API objects that are not already part of the IAC support system.

I'm interested in finding more documentation on this topic.  Exactly how does a custom plug-in expose functionality to the IAC?

Does anyone have experience with this topic, and/or know of any documentation on it? 

This topic has been closed for replies.
Correct answer Thom Parker

Looks like the answer is in the References, although I won't be able to test it right away to be sure.

There are two functions for handling COM interfaces. One in the plug-in SDK, and one in the IAC SDK.

WinAppRegisterInterface - on the plug-in side registers a COM interface with Acrobat.

GetInterface - On the IAC side acquires the interface.

It would be nice if these functions, or more info on the process was mentioned/linked on the page that mentions it's possible.

1 reply

T
Test Screen Name
Legend
February 7, 2018

Hmm, based on what I remember from study long ago... to say that IAC can be extended is rather stretching a point. But a plug-in can certainly expose IAC methods, using COM or other interfaces, to other apps. Particular Complications.

1. It gets messy because the OLE objects in Acrobat's IAC methods are opaque to their IAC; a plug-in has no hooks to convert a received OLE object from AVDoc (OLE) to AVDoc (plug-in). That said, there are probably ingenious ways to at least convert AVDoc and PDDoc objects.

2. A plug-in must not wait, but providing a service is typically based on waiting. This may be overcome using a secondary thread but...

3. The plug-in API can only be used from the main thread, and there is no way to call a routine in the main thread. This means that messages would have to be posted to the main thread, perhaps using Windows messages, perhaps using Idle procs.

Thom Parker
Community Expert
Thom ParkerCommunity ExpertAuthor
Community Expert
February 8, 2018

So how do you expose IAC methods through a plug-in? After all they are already exposed to external apps. That's the whole point of the IAC.

That last bit in the sentence, " core API objects that are not already part of the IAC support system."   implies the IAC can be extended to more than is already there. That in fact custom functionality can be added to the IAC.  If this is true, then it's a great thing. Cause the only other ways to pass data from an external app to an Acrobat plug-in is DDE, or indirectly through JS. There are probably also some existing IAC methods that could be used for this purpose, but I'm very keen on the more direct approach if it is possible.

Thom Parker - Software Developer at PDFScriptingUse the Acrobat JavaScript Reference early and often
Thom Parker
Community Expert
Thom ParkerCommunity ExpertAuthorCorrect answer
Community Expert
February 8, 2018

Looks like the answer is in the References, although I won't be able to test it right away to be sure.

There are two functions for handling COM interfaces. One in the plug-in SDK, and one in the IAC SDK.

WinAppRegisterInterface - on the plug-in side registers a COM interface with Acrobat.

GetInterface - On the IAC side acquires the interface.

It would be nice if these functions, or more info on the process was mentioned/linked on the page that mentions it's possible.

Thom Parker - Software Developer at PDFScriptingUse the Acrobat JavaScript Reference early and often
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices