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.

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.