How To Programmatically Enable/Disable 'Display PDF In Browser' For Acrobat / Reader XI or DC For Use With Adobe ActiveX Control

Question

We have a .NET C# application that makes use of the Adobe ActiveX Controls. For versions 7-10 of both Adobe Acrobat and Adobe Reader, to use this control you were required to turn on the "Display PDF In Browser" setting. You could do this manually from the GUI using

Preferences > Internet > Display PDFs in browser

or programmatically by setting the registry settings directly

HKEY_CURRENT_USER\Software\Adobe\(Product Name)\(Version)\Originals
"bBrowserIntegration"=dword:00000001

Which follows the SDK reference http://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/Windows/Originals.html#BrowserIntegration. Our application has been using the programmatically setting of this registry value when our customers have versions 7-10 of Adobe Reader or Adobe Acrobat. The link above also indicates that this bBrowserIntegration registry key is deprecated in XI (11). The old registry path still exists in the new versions, i.e.:

HKEY_CURRENT_USER\Software\Adobe\(Product Name)\(Version)\Originals

however there is no longer a bBrowserIntegration key just as the documentation indicates, it is deprecated.

It does appear that the Adobe ActiveX Control still works just fine with XI and DC as long as Display PDF in Browser is enabled, as it always has.

For versions XI (11) and DC, there are two published links that clearly show how to achieve this manually:

XI (11): https://helpx.adobe.com/acrobat/11/using/display-pdf-browser-acrobat-xi.html
DC (current): https://helpx.adobe.com/acrobat/using/display-pdf-in-browser.html

When testing Adobe Reader DC, if we don't complete the steps to enable the Display PDF in Browser for a new customer installation, then our application will throw a COM error and then if we enable the setting following the instructions in the link above, everything works as expected with our application, it renders PDFs using the Adobe ActiveX Control, which is similar to what we expect to see in older versions (7-10) when the registry setting was not set (see my old post and my own solution back then How to diagnose cause, fix, or work around Adobe ActiveX / COM related error 0x80004005 progmatically?).

So, the question remains, what is the expected programmatic equivalent either for the manual process in XI or DC today or the equivalent to what worked in 7-10 by setting the registry setting bBrowserIntegration accordingly. We want to be able to turn it on and then reset it to the previous setting when our application ends (so our application doesn't force the user to keep the setting just because our application needs it) which is what we do today for 7-10.

I can't seem to find any references online for how to enable/disable browser integration from a developer standpoint so our application can continue to the use the ActiveX Control and not have the COM errors show up, forcing the user to change this manually.

The primary priority is to understand the solution for DC as this represents the new paradigm for Adobe Acrobat/Reader.

Whiten

Are you navigating a WebBrowser control to a PDF file? Or hosting Acrobat Reader ActiveX directly? – Latoshalatouche

We are using the inter application hosting of the Adobe Acrobat ActiveX Control in our app to display PDFs, NOT using a web browser control in the app. Using the ActiveX Control requires the 'display pdf in browser' settings as if you were using IE itself to display the PDF – Whiten

Answer 1

Have you considered the use of "Registration free" scenario? It allows to use COM/ActiveX components in your application without registering the ActiveX globally and allows to load the isolated COM/ActiveX control for your application only based on the interfaces defined in the XML manifest included along with your application.

See this post for the list of tools and this post for sample XML manifest to use Flash plugin and this step by step guide. I assume that for Adobe Reader control you should use PDF.ocx from C:\Program Files\Adobe\Acrobat \Reader\ActiveX folder.

UPDATE (July 27 2015): In the latest versions of Adobe Reader they use AcroPDF.dll and moved it into \Program Files\Common Files\Adobe\Acrobat\ActiveX\ as I've checked with Adobe Reader 11. Unfortunately AcroPDF.dll throws error when trying to install it using regsvr32.exe. I suppose it checks some additional keys before initializing to protect from non permitted use (until user unblocks the control in IE). Seems like there is not way officially and programmatically walk around the requirement for user to explicitly permit PDF control for use by non-Adobe apps.

Also see the discussion regarding possible issues on x64 platform: the better and more reliable way is to use Adobe Reader control indirectly by hosting IE’s WebBrowser control that will invoke the embedded PDF viewer control accordingly.

Salter

Thanks, sounds interesting, however its not clear to me how this would solve the immediate problem. We don't have a registration problem as far as I can tell. The Adobe ActiveX libraries (AxAcroPDFLib.dll & AcroPDFLib.dll) we provide in our app designed to interact with whichever PDF program is installed (Reader or Acrobat) have required the setting "Display PDF in Browser" to be turned from version 7-10 or we get the COM error. The settings have just been removed/moved for 11 & DC and an install option sets this now. This setting affects whether the COM error shows up or not. – Whiten

This could help to use the Adobe Reader activex control even if it is not registered in the system (i.e. not available in IE) by simply referencing it from the XML manifest so it will be available for your app only as it were registered globally. It is possible to do with flash player control but need to try with Adobe Reader to make sure it works for it as well. – Salter

When you say "even if its not registered in the system" ... are you saying that is the same affect as what used to happen with the previous version's setting "Display PDF in Browser" in Preferences? As far as I can tell, it was a registry issue, not a registration issue. The main objective is how to enable the current equivalent of what used to be a setting we could access in the registry, not that we were "registering" anything when we enable this setting. Are you saying these two things are the same? – Whiten

"Using the ActiveX Control requires the 'display pdf in browser' settings as if you were using IE itself to display the PDF" - it means that if user enables this, then Adobe Reader "registers" the COM object (PDF.ocx) and the it becomes available for IE, for your app and others. Once user disables, Adobe Reader "deregisters" this global COM object (i.e. viewer control). That is why I suggest you to try registration-free scenario that may help you to use PDF.ocx even if it is not globally "registered". – Salter

in other words try to register PDF com control for IE manually with the command: regsvr32 "c:\Program Files\Adobe\Acrobat 6.0\Reader\ActiveX\pdf.ocx" in As Admin mode – Salter

Thanks for your explanation. I understand now why you are suggesting the registration free process. With your pointer to using "pdf.ocx", is this as a replacement to the Adobe ActiveX libraries (AxAcroPDFLib.dll & AcroPDFLib.dll) we provide in our app? That part is not yet clear to me. Does pdf.ocx replace those two and we can switch and no longer need to provide those dlls with our app? – Whiten

Also, I just found this adobe.com/support/techdocs/318268.html and it says at the bottom "The Acrobat Control is designed specifically for use with Internet Explorer; it is not a full-featured ActiveX Control that you can use to enable applications other than Internet Explorer to display PDF files." so I am wondering if this PDF.ocx is really the same COM control that our current Adobe ActiveX implementation is using or is it some other COM object? As well as this forums.adobe.com/thread/746286 vi – Whiten

As well as this forums.adobe.com/thread/746286 which reads "PDF.OCX was a VERY OLD (pre-Acrobat 8) UNSUPPORTED component. As of Acrobat 8, we now offer the AcroPDF.dll which is a SUPPORTED part of the SDK." which makes me curious if this PDF.ocx is a path that isn't part of the current Adobe Reader DC implementation. Do you know the details or explanations? – Whiten

Yes, they moved to AcroPDF.dll into \Program Files\Common Files\Adobe\Acrobat\ActiveX\ and I've just checked with Adobe Reader 11. Unfortunately AcroPDF.dll throws error when trying to install it using regsvr32.exe. I suppose it checks some additional keys before initializing to protect from non permitted use (until user unblocks it in IE). Here are some additional links for you to check experts-exchange.com/Software/Internet_Email/Web_Browsers/… and forums.adobe.com/thread/1475520 (regarding use on x64 platform). – Salter

And seems like there is not way officially and programmatically walk around the requirement for user to explicitly permit PDF control for use by non-Adobe apps. – Salter