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

Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
Same problem here. Accessing the ActiveX from a Delphi application also don't work. Worked fine with 11.0.06 but not with 11.0.07. Need an update asap!
Regards
Simon

Copy link to clipboard
Copied
Could we get some answer on this? This problem is really annoying and i bet there are alot of developers affected by this.
Thanks
Copy link to clipboard
Copied
I'm using AcroPDF.dll ActiveX in a VB6 application for years in my company. Since update 11.0.07 application crashes. I would appreciate a solution.
Copy link to clipboard
Copied
Add me to the list.
We are using 'pdfviewer' from acroPDF.PDF in VB6 for years now.
Since the update to 11.0.0.7 our hotline is running hot
The problem is, we don't have an influence on what version of acrobat reader our customers install and whether they use the automatic update function.
Please inform us, if you have a workaround or better still a solution
Copy link to clipboard
Copied
I suggest that, as well as waiting for a reply, that each of you report this as a bug.

Copy link to clipboard
Copied
Where can i report a Bug?
Thanks
Stefan
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Ok, I have reported it now.
Let's hope it has an effect soon

Copy link to clipboard
Copied
Reported as well, hopefully this will be solved soon.
I also found the solution to embed the Control within a .NET Control. I already heavily work with the Interop Control Toolkit within my project. If there is no solution in the near future i will implement this in .NET as well.
Stefan

Copy link to clipboard
Copied
I reported it too.
Regarding embedding in .NET control, how about printing? I found some stability issues playing with focus (switching from and back to my test app while it was printing caused a crash in the control, but only on Windows 8 - on Windows 7 apparently this does not happen). No other problem until now.
Copy link to clipboard
Copied
We are currently investigating this issue to determine the cause and how soon we can issue a fix!
Copy link to clipboard
Copied
Is there any news on this issue? I have 70+ users of a macro that uses this feature.
I understand that a fix may not be easily done, but an update would be helpful.
Thanks
Copy link to clipboard
Copied
As soon as we have more info, we'll post it.
We are well aware of the problems this is causing and we are doing as much as we can!
Leonard

Copy link to clipboard
Copied
Same problem, I'm currently experimenting with embedding AcroPDF into an Interop User Control (C#). It seems to work as long as displaying a document is concerned, while there are maybe some issues with printing (PrintWithDialog() method).
Kludgy solution, I know, but my app already uses some .NET components so no more extra load and maybe this will fit my needs al least temporarily...

Copy link to clipboard
Copied
We are having the same issue with Adobe Reader 11.0.07.
We are embedding the AcroPDF.PDF using AXHost and our call to create the control fails with an access violation.
hr = AtlAxCreateControlLic( OLESTR("AcroPDF.PDF"), m_wndMain.m_axwnd.m_hWnd, NULL, NULL );
This is impacting our customers as we have no control over when they update. I too would like fix as soon as possible and have also reported it via the Bug Report link above.

Copy link to clipboard
Copied
I am a developer of an Italian software house.
Our product is developed in Delphi.
The display of *. Pdf via TAcroPDF no longer works for many of our customers and we are in serious trouble.
Best Regards
Carlo
Copy link to clipboard
Copied
OK - here is the situation.
With Reader 11.0.7, we (finally!) now provide a 64bit version of AcroPDF.dll so that Reader can be used in 64bit browsers! Great news for customers.
However, that means that anyone who built an application with an older development environment (eg. VB6) that doesn't know from 64bit DLLs (or "universal" 32/64bit DLLs) will no longer be able to load AcroPDF. As these older environments have not been supported by Adobe for many years now (I think we dropped support for VB6 around Acrobat 9), we didn't test this scenario.
For those of you who are using modern development environment but had previous built your apps as 32 bit (because of AcroPDF) - you can now simply rebuild as either 64 only or "Any" and not only will things work again but you're app will now be 64bit!
Hope that helps everyone understand the situation and how to remedy it.
If you have any questions, please don't hesitate to ask.
Copy link to clipboard
Copied
So, you are saying anything built in vba for excel, regardless of the version, is no longer supported?
Admittedly, I am not a professional programmer. Does this mean I just have to remove anything Adobe from my macros? Or will there be something later we can use?
Copy link to clipboard
Copied
I didn't say anything about VBA - I commented only on VB6. We have not done any testing with VBA in Excel (or other applications).

Copy link to clipboard
Copied
Hello,
is it planned to restore this 32bit Support in the future or is this feature gone?
Thanks in advance for your answer.
Stefan

Copy link to clipboard
Copied
Well before I wait for a solution from Adobe here is my solution using the Interop Control Toolkit from MS
Hopefully this will help out some of you using the good old 32Bit Developement Evnironments 😉
Public Class AxControl
Inherits AxHost
Public Sub New(ByVal strCLSID As String)
MyBase.New(strCLSID)
End Sub
End Class
Private WithEvents m_axCtrl As AxControl
Private strProgId As String
Private m_type As Type
Private args As Object()
Private Function GetControl() As AxControl
Dim bolErr As Boolean
Try
strProgId = "AcroPDF.PDF"
m_type = System.Type.GetTypeFromProgID(strProgId, True)
m_axCtrl = New AxControl(m_type.GUID.ToString())
bolErr = False
Catch
bolErr = True
End Try
If bolErr = True And m_axCtrl Is Nothing Then
Try
strProgId = "pdf.pdfctrl.6"
m_type = System.Type.GetTypeFromProgID(strProgId, True)
m_axCtrl = New AxControl(m_type.GUID.ToString())
bolErr = False
Catch
bolErr = True
End Try
End If
If bolErr = True And m_axCtrl Is Nothing Then
Try
strProgId = "pdf.pdfctrl.5"
m_type = System.Type.GetTypeFromProgID(strProgId, True)
m_axCtrl = New AxControl(m_type.GUID.ToString())
bolErr = False
Catch
bolErr = True
End Try
End If
If bolErr = True Or m_axCtrl Is Nothing Then
Return Nothing
Else
Return m_axCtrl
End If
End Function
Public Function InitAdobeReader(ByVal pFile As String) As Boolean
If GetControl() Is Nothing Then
Return False
End If
Try
DirectCast((m_axCtrl), System.ComponentModel.ISupportInitialize).BeginInit()
m_axCtrl.Enabled = True
m_axCtrl.Name = "axCtrl"
m_axCtrl.TabIndex = 0
m_axCtrl.Left = 0
m_axCtrl.Top = 0
m_axCtrl.Width = Me.Width
m_axCtrl.Height = Me.Height
Controls.Add(m_axCtrl)
DirectCast((m_axCtrl), System.ComponentModel.ISupportInitialize).EndInit()
args = New Object() {False}
m_type.InvokeMember("setShowToolbar", BindingFlags.InvokeMethod, Nothing, m_axCtrl.GetOcx, args)
args = New Object() {pFile}
m_type.InvokeMember("LoadFile", BindingFlags.InvokeMethod, Nothing, m_axCtrl.GetOcx, args)
Return True
Catch
Return False
End Try
End Function
Public Sub Destroy()
m_axCtrl.Dispose()
cMemoryManagement.FlushMemory()
End Sub
Private Sub InteropUserControl_Resize(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Resize
If m_axCtrl Is Nothing Then Return
m_axCtrl.Top = 0
m_axCtrl.Left = 0
m_axCtrl.Width = Me.Width
m_axCtrl.Height = Me.Height
End Sub

Copy link to clipboard
Copied
As I wrote some days ago, I started testing with Interop User Control, too, and it seems working (I understand Adobe's point of view, but as many others I too have older software that I cannot still drop support for, and I can't control what my customers install and update nor can I tell them to not update...). Did you have any issue with printing, e.g. printWithDialog() method?

Copy link to clipboard
Copied
No issue by now with printing. I call the printWithDialog Function
Public Sub printWithDialog()
m_type.InvokeMember("printWithDialog", BindingFlags.InvokeMethod, Nothing, m_axCtrl.GetOcx, Nothing)
End Sub

Copy link to clipboard
Copied
The issue I had was a "crash" of the control (but not the host application, resulting in a grey rectangle...): if I switched to anothed application and then returned to my test app while it was printing, as soon as the printing progress regained the focus it crashed with the "adobe reader has stopped working" message... but maybe an issue with my develop machine (win 8.1, 64 bit), on another one (win 7, 32 bit) this doesn't happen...

