The AcroPDF.PDF Class is no longer accessible from VisualBasic6 after update 11.0.0.7.

[Guest]

After upgrading to 11.0.0.7 of Acrobat Reader it is no longer possible to get an instance of the AcroPDF.PDF Control in Visual Basic 6

Private PDFExt As VBControlExtender

Set PDFExt = Me.Controls.Add("AcroPDF.PDF", "PDF")

This worked fine with the 11.0.0.6 Version of the Reader!

Is there any solution available?

Thanks in advance

Stefan

[Guest]

I have to partially correct my previous statement, the issue I found during a long print doesn't happen switching to another application and then back to my test app while the printing progress dialog is displaying, but clicking somewhere on the main form area... I know, it shouldn't happen, because the progress dialog is modal (or it should be... of course when printing from Adobe Reader itself the behaviour is as expected), but apparently the focus actually moves to the main form, and as soon as I select the printing dialog again, the "Adobe Reader has stopped working" message appears... this inconvenience happens to me both dropping the Acrobat 7.0 Browser Control directly into my control at design time as I did originally and implementing Stef4Life's solution, and is the only issue that temporarily stops me from starting the Interop User Control way in a test release of my real application. I'm surely missing something here, and will keep experimenting...

[Gerson008]

I'm trying to work out your code, how does it work?

Which version of visual studio did you use?

Is the "AxControl" class is one file (e.g. AxControl.vb) and the rest are put in "InteropUserControl.vb"

[Angry32BitUser]

Hello,

we are currently developing with Delphi XE5. A quite actual development environment.

We develop industry-specific software in Win32, a still very current platform when the reality of what kind of software exists, is not ignored.

If this is to be an 64bit DLL now, why do we still find it in program files (x86). This is irritating.

The statement made ​​here seems to be not well-founded 100%.

I'm sorry, but i just can't belive that Adobe sits down here and says: we do not care about the existing Programs outside there.

We and many customers need a working 32Bit Version of AcroPDF.dll

[lrosenth]

The DLL is available as a BOTH 32 and 64 bit. The problem is that older development environments (such as VB6) don't know how to load the correct one in such a situation - it simply loads the first one that it finds. If you simply recompile the same project with a modern and supported environment (say VB.NET) - even as a 32bit app(!) - then the correct one will be loaded. It's simply the DLL loader "under the covers" of your environment.

I don't know anything about Delphi and it is not an officially supported environment (see <http://www.adobe.com/devnet/acrobat/overview.html#IAC>), so I can't comment on it - but I suspect that it's the same situation.

As for "caring about existing programs" - we admit to not having considered that this change would have such an impact - and for that we apologize. However, there is no "fix" that we can issue - this is an unfortunate design choice of Microsoft when they moved to 64bit. If you search the web, you will find NUMEROUS other cases of this same thing with other developers and libraries - including MSFT itself.

[Guest]

I don't understand Adobe why its not possible to build a 32bit version as a package only rename file if need be like AcroPDF32.dll then make no further changes to it and have a separate package for 64bit.

This way you are able to have both the 32bit and 64bit versions of your product installed and everyone would be happy. This method wouldn't be reliant on Microsoft OS deciding correct dll version to load as there would be only one choice for the package ... we know this works because users have been okay from v9 up to v11.0.6 where you claim not to support VB6 anymore ???

[MonaLisaML]

I agree with you there.

We are using the pdfviewer-control since Acrobat 5 and have now 3 different classnames in our program ("AcroPDF.PDF", "PDF.PdfCtrl.6", "PDF.PdfCtrl.5"), that we try one after the other. It would really be the easiest thing just to add another one e.g. AcroPDF32.PDF.

That shouldn't be a too big a problem for Adobe and would probaly help a lot of otherwise very unhappy programmers 😉

By the way: The Adobe statement about VBA seemed a bit like a bad joke to me...

[Gerson008]

I think for developer who needs to make serious changes on this issue, should considered removing the dependency on Adobe reader.

There are heaps of PDF reader that can do the jobs, however if you need the javascript interaction within a PDF document, i'll bluntly put it, "You're STUFF" (well pretty much the tone from the support here). Because your client program will not be able to initiate the class on acroPDF.pdf in 32bit mode.

I'm trying a quick fix and see if i can initiate the class during runtime in VB6, if that doesn't work, i may have to write my own PDF reader based on some open source from muPDF, SumatraPDF etc. With SumatraPDF, they have no intentions of moving to 64bits and it's compatible with Windows. Maybe something for developer to think about. Of course you need to learn C/C++.

Alternatively you can redeveloped your application all together.

Clearly the support here have no idea that IBM 360 mainframe are still running in today's so call fast pace software world, the same with the 20million VB6 developers.

[luisfco]

I live in LA (Mexico City).  here there are yet al lot of not 64bit computers and software in obsolete developing systems, so you are telling us to look for another solution for all the software that is already installed. to modify all that or die. we don´t even have the source code of some of that software, It is very disapointing comming from a company like Adobe.

[Yadvinder_Salh]

Hi,

I am Yadvinder from Vertex Infosoft. We are already under agreement from Adobe, allowed to re-distribute Adobe Reader and same problem at our end has occurred. We now have to update all our clients. Can adobe allow us to distribute old version of AcroPDF.PDF in our standard setup build using installshield. So we will use this DLL in our installation folder. We tested here at our end by copying DLL and it worked fine. If Adobe allows us then we can deploy 500 old installations with a patch else we need to add .Net Framework in our setup and send CD to all remote locations. Our software is used on ships and sending CD to each ship may take 6 months.

If Adobe accepts this request we would be very grateful.

[lrosenth]

Yadvinder, you will need to contact our legal department for permission. The relevant contact will be in your contract.

[Guest]

I looked into the idea if the old 32 bit version of the AcroPDF.dll file can be installed as well as the 64 bit version so they both co-exist.

I found that both versions of the dll have been built to use the same GUID which I believe means that they can't co-exist unless Adobe builds the 64 bit version with new GUID, this was my previous suggestion for Adobe when I was talking about separate packages.

Therefore I think your installer will possibly work in the short term but when a user runs update your install will be broken. Alternatively the users where you install the old AcroPDF.dll will break any other app that requires the 64 bit version.

[Yadvinder_Salh]

Many thanks for the above. It has helped me in taking a decision to change our software instead thinking of workarounds.

[Guest]

Thanks for your reply, may I ask what type of change you were thinking of doing, would you be upgrading your software to .Net for example?

[Guest]

Hello,

Where can I get the 64-bit version of AcroPDF.dll ?

Thanks

[lrosenth]

No such product exists. Adobe Acrobat, including Reader, is still a 32-bit only product.

[Guest]

just scroll above to see the previous replies where they stated the existence of 64-bit

thanks

[lrosenth]

I don’t know who “they” are, but Adobe Systems has NEVER stated that there exists a 64bit version of our DLLs – because there isn’t.

[Guest]

and then how will Adobe line with technologies? if 64-bit is not there yet?

one of the major problems spreading the internet nowadays -and for long back- can be solved of introducing 64 bit DLLs

[lrosenth]

64bit has nothing to do with the internet, and in fact, it’s not always a good thing. Many vendors continue to provide 32bit applications – Microsoft, Google, etc.

[Guest]

Sometimes I blame my English language, but when I read again and again, I found it very descriptive, when I said "one of the major problems spreading the internet nowadays -and for long back- can be solved of introducing 64 bit DLLs" ... how did you get to relate that with internet so you came up with your reply "64bit has nothing to do with the internet" ???

if you just do a little google search, for "Adobe PDF Reader" and "Visual Studio" you will see what is meant by the sentence and what is meant b 64-bit DLLs in modern technologies, and then you will figure out all stuff ..

Cheers

[sheristeeves]

We noticed that there was a 64-bit version of the DLL and thought, like you said, that we would have to recompile our component to be 64-bit, so we tried that approach.

The problem is that even with our C++ COM component compiled 64-bit we STILL get the same error.

When we call :

    hr = AtlAxCreateControlLic( OLESTR("AcroPDF.PDF"),  m_wndMain.m_axwnd.m_hWnd,  NULL,  NULL  );

we get an access violation with the following call:

Call to  m_spOleObject->SetClientSite(spClientSite) will access violation (null pointer exception) in AcroPDF.DLL or AcroPDF64.DLL.  Does not matter whether 32-bit or 64-bit compiled!!!!

Callstack from debugging:

Atlhost.h:

HRESULT ActivateAx(

_Inout_opt_ IUnknown* pUnkControl,

_In_ bool bInited,

_Inout_opt_ IStream* pStream)

{

if (pUnkControl == NULL)

return S_OK;

m_spUnknown = pUnkControl;

HRESULT hr = S_OK;

pUnkControl->QueryInterface(__uuidof(IOleObject), (void**)&m_spOleObject);

if (m_spOleObject)

{

m_spOleObject->GetMiscStatus(DVASPECT_CONTENT, &m_dwMiscStatus);

if (m_dwMiscStatus & OLEMISC_SETCLIENTSITEFIRST)

{

CComQIPtr<IOleClientSite> spClientSite(GetControllingUnknown());

m_spOleObject->SetClientSite(spClientSite); 

}

if (!bInited) // If user hasn't initialized the control, initialize/load using IPersistStreamInit or IPersistStream

{

CComQIPtr<IPersistStreamInit> spPSI(m_spOleObject);

if (spPSI)

{

if (pStream)

hr = spPSI->Load(pStream);

else

hr = spPSI->InitNew();

}

else if (pStream)

{

CComQIPtr<IPersistStream> spPS(m_spOleObject);

if (spPS)

hr = spPS->Load(pStream);

}

if (FAILED(hr)) // If the initialization of the control failed...

{

// Clean up and return

if (m_dwMiscStatus & OLEMISC_SETCLIENTSITEFIRST)

m_spOleObject->SetClientSite(NULL);

m_dwMiscStatus = 0;

m_spOleObject.Release();

m_spUnknown.Release();

return hr;

}

}

if (0 == (m_dwMiscStatus & OLEMISC_SETCLIENTSITEFIRST))

{

CComQIPtr<IOleClientSite> spClientSite(GetControllingUnknown());

m_spOleObject->SetClientSite(spClientSite);

}

m_dwViewObjectType = 0;

hr = m_spOleObject->QueryInterface(__uuidof(IViewObjectEx), (void**) &m_spViewObject);

if (FAILED(hr))

{

hr = m_spOleObject->QueryInterface(__uuidof(IViewObject2), (void**) &m_spViewObject);

if (SUCCEEDED(hr))

m_dwViewObjectType = 3;

} else

m_dwViewObjectType = 7;

if (FAILED(hr))

{

hr = m_spOleObject->QueryInterface(__uuidof(IViewObject), (void**) &m_spViewObject);

if (SUCCEEDED(hr))

m_dwViewObjectType = 1;

}

CComQIPtr<IAdviseSink> spAdviseSink(GetControllingUnknown());

m_spOleObject->Advise(spAdviseSink, &m_dwOleObject);

if (m_spViewObject)

m_spViewObject->SetAdvise(DVASPECT_CONTENT, 0, spAdviseSink);

m_spOleObject->SetHostNames(OLESTR("AXWIN"), NULL);

if ((m_dwMiscStatus & OLEMISC_INVISIBLEATRUNTIME) == 0)

{

GetClientRect(&m_rcPos);

m_pxSize.cx = m_rcPos.right - m_rcPos.left;

m_pxSize.cy = m_rcPos.bottom - m_rcPos.top;

AtlPixelToHiMetric(&m_pxSize, &m_hmSize);

m_spOleObject->SetExtent(DVASPECT_CONTENT, &m_hmSize);

m_spOleObject->GetExtent(DVASPECT_CONTENT, &m_hmSize);

AtlHiMetricToPixel(&m_hmSize, &m_pxSize);

m_rcPos.right = m_rcPos.left + m_pxSize.cx;

m_rcPos.bottom = m_rcPos.top + m_pxSize.cy;

CComQIPtr<IOleClientSite> spClientSite(GetControllingUnknown());

hr = m_spOleObject->DoVerb(OLEIVERB_INPLACEACTIVATE, NULL, spClientSite, 0, m_hWnd, &m_rcPos);

RedrawWindow(NULL, NULL, RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE | RDW_INTERNALPAINT | RDW_FRAME);

}

}

CComPtr<IObjectWithSite> spSite;

pUnkControl->QueryInterface(__uuidof(IObjectWithSite), (void**)&spSite);

if (spSite != NULL)

spSite->SetSite(GetControllingUnknown());

return hr;

}

[Guest]

This doesn't work in Delphi XE6.

following your argument I changed an application to 64 bit.

The TAcroPDF component created from AcroPDF.dll is greyed out (because its recognized as 32 bit).  The AcroPDF46.dll doesn't appear at an available ActiveX component to import.

reverting to 32 bit for the application, if I try and add the TAcroPDF component to a from I get a read error in the AcroDLL at 600B9996.

we are currently reverting to older versions of Abobe

Thanks a lot !

[Guest]

Added

function QueryInterface(const IID: TGUID; out Obj): HResult; override;

to AcroPDFLib_TBL.pas as per

https://forums.adobe.com/message/6400731#6400731

rebuilt the ActiveX package and now works in Delphi XE6

[Guest]

Currently on the market are still 32-bit operating system (32-bit Win8 for example).
It 's absurd that AcroPDF no longer supports 32-bit applications.

Best Regards

Carlo

[Guest]

Totally agree with what you say.

Please can someone from Adobe please confirm whether or not a fix will be available especially for those of us who still develop only 32 bit applications (we're still on Delphi 2007). It has been a week now since the release and I would expect a little more clarity from you.

I find it quite bizarre that such a major impact change was made in such a minor release from 11.0.06 to 11.0.07!!

So far, I find Adobe's attitude on this somewhat cavalier.