VB6 is not supported with Reader X.
From: Adobe Forums <forums@adobe.com<mailto:forums@adobe.com>>
Reply-To: "jive-1134247383-8igo-2-2e4on@mail.forums.adobe.com<mailto:jive-1134247383-8igo-2-2e4on@mail.forums.adobe.com>" <jive-1134247383-8igo-2-2e4on@mail.forums.adobe.com<mailto:jive-1134247383-8igo-2-2e4on@mail.forums.adobe.com>>
Date: Thu, 10 Nov 2011 08:19:16 -0800
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Subject: Re: AccessViolationException fatal error, Acrobat 9, AxAcroPDFLib, .NET, Win7 AccessViolationException fatal error, Acrobat 9, AxAcroPDFLib, .NET, Win7
Re: AccessViolationException fatal error, Acrobat 9, AxAcroPDFLib, .NET, Win7
created by james.g.taylor<http://forums.adobe.com/people/james.g.taylor> in Acrobat SDK - View the full discussion<http://forums.adobe.com/message/4018487#4018487
Here is a workaround for WPF with .NEt 3.5 and Reader X :
add In "Window_Loaded" :
ComponentDispatcher.ThreadFilterMessage += new ThreadMessageEventHandler(ComponentDispatcher_ThreadFilterMessage);
private void ComponentDispatcher_ThreadFilterMessage(ref MSG msg, ref bool handled)
{
if (msg.message == 0x1450)
handled = true;
}
Regards,
H.M
Hi Dustin,
You could probably use Parameters for openning PDF Files in your case. On the last page of the document they describe how to encode the parameters into the URL
aucha
The parameters work great. The thing is that I still need to have an easier way for the user to print the document from GUI in the parent application. Is there a way to reference the PDF and have it open the print dialog using something like javascript? Or even better, an undocumented parameter to open the print diaglog prompt?
DBuschow wrote:
The parameters work great. The thing is that I still need to have an easier way for the user to print the document from GUI in the parent application. Is there a way to reference the PDF and have it open the print dialog using something like javascript? Or even better, an undocumented parameter to open the print diaglog prompt?
Yes you can. See this document. However, next time please start a new thread rather than asking off-topic questions.
yes I agree thank you dbuschow ukash ukash kart
For any that need a fix for this in Access/VBA the solution for me was to use a low level keyboard hook. Sub classing the window proc causes all sorts of gimpy behvior in access, even a window proc that does nothing more than call the default window proc. Instead you can install a WH_KEYBOARD_LL hook and supress the tab key on the form housing the acrobat control. For some folks this will be a problem (tabbing through controls) however we personally use the pdf control on its own dialog outside the main access window so it works fine for us. I'm not sure how it affects pdf forms either, again a non-issue for us. Any how, here's the code, adapt it for your needs:
' Win32 Module Public Const WH_KEYBOARD_LL = 13 Public Type KBDLLHOOKSTRUCT vkCode As Long scanCode As Long flags As Long Time As Long dwExtraInfo As Long End Type Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, wParam As Any, lParam As Any) As Long Public Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As Any) As Long Public Declare Function GetActiveWindow Lib "user32.dll" () As Long
' Some other module ' Please note the keyboard hook procedure HAS to be in a module, AddressOf will not work ' for a function inside a form module. Public Property Get KeyboardHookHandle As Long KeyboardHookHandle = ' where ever the handle of the hook is stored End Property Public Property Let KeyboardHookHandle(val as Long) ' store the hook handle in global variable, in a control on a form, wherever you like.... End Property ' Form_PdfViewer is the form that holds the adobe pdf viewer control Public Function KeyboardHook(ByVal nCode As Integer, wParam As Long, lParam As Win32.KBDLLHOOKSTRUCT) As Long If nCode >= 0 Then If lParam.vkCode = vbKeyTab And Win32.GetActiveWindow() = Form_PdfViewer.hwnd Then Debug.Print "Aborted tab key press!" DoEvents KeyboardHook = 1 Exit Function End If End If DoEvents KeyboardHook = Win32.CallNextHookEx(KeyboardHookHandle, nCode, wParam, lParam) End Function
' The form housing the adobe pdf viewer control Private Sub Form_Load() KeyboardHookHandle = Win32.SetWindowsHookEx(Win32.WH_KEYBOARD_LL, AddressOf KeyboardHook, Win32.GetModuleHandle(vbNullString), 0) End Sub Private Sub Form_Unload(Cancel As Integer) Win32.UnhookWindowsHookEx KeyboardHookHandle End Sub
Another alternative is to use the web browser control which works fine in access 2003 on windows 7 with ie9 however you can't resize the control on windows xp with access 2002 and ie8 and unfortunately we still have users with that configuration so it's not an option for us.
Thanks hugely jptros, this (ignored by Adobe) bug has been annoying me for quite a while. I'd implemented a kludge to handle the tab but your solution is much better.
I had to fiddle with it a bit to get it to work for me - in case anyone else needs it, my adjusted version is pasted below.
' Until Adobe get around to fixing the bug with the Tab key, have this in a stand alone module
' When (if) it's fixed, delete the module and remove the references in the Form_Load and Form_Unload on any forms that are referencing this code
Option Compare Database
Option Explicit
' This lot are used to hook the [TAB] key on forms showing the Acrobat PDF viewer control
' because of the bug in their code that causes Access to lock up.
' http://forums.adobe.com/thread/530591?tstart=0
Public Const WH_KEYBOARD_LL = 13
Public Type KBDLLHOOKSTRUCT
vkCode As Long
scanCode As Long
flags As Long
Time As Long
dwExtraInfo As Long
End Type
Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long
Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long
Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, wParam As Any, lParam As Any) As Long
Public Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As Any) As Long
Public Declare Function GetActiveWindow Lib "user32.dll" () As Long
Dim gKeyboardHookHandle As Long
Public Property Get KeyboardHookHandle() As Long
KeyboardHookHandle = gKeyboardHookHandle
End Property
Public Property Let KeyboardHookHandle(val As Long)
' store the hook handle in global variable, in a control on a form, wherever you like....
End Property
Public Function KeyboardHook(ByVal nCode As Integer, wParam As Long, lParam As KBDLLHOOKSTRUCT) As Long
Dim hwnd_Form_PDFViewer As Long
' I'm only using the PDF viewer on a single form so only care about a single hwnd
If Screen.ActiveForm.Name = "frmDocumentArchive" Then hwnd_Form_PDFViewer = Screen.ActiveForm.hwnd
If nCode >= 0 Then
If lParam.vkCode = vbKeyTab And GetActiveWindow() = hwnd_Form_PDFViewer Then
Debug.Print "Aborted tab key press!"
DoEvents
KeyboardHook = 1
Exit Function
End If
End If
DoEvents
KeyboardHook = CallNextHookEx(KeyboardHookHandle, nCode, wParam, lParam)
End Function
'---- From here on, these are in the form which needs the [TAB] presses to be consumed to prevent the crash.
Private Sub Form_Load()
' Handle the Acrobat bug
KeyboardHookHandle = SetWindowsHookEx(WH_KEYBOARD_LL, AddressOf KeyboardHook, GetModuleHandle(vbNullString), 0)
End Sub
Private Sub Form_Unload(Cancel As Integer)
' Clean up after handling the Acrobat bug
UnhookWindowsHookEx KeyboardHookHandle
End Sub
I spoke to soon.
Maybe it's the changes I made - but this code consumes all TAB presses in all windows, not just the ones in Access... and then Access crashes when you exit the application.
Looks like the same crash that would have occurred without this hook consuming the key presses.
Improvement over crashing any time that Tab is pressed when the form with the reader control is open and the control is populated, but still doesn't resolve the problem.
Ah well, rolling back to my bodgy fix.
Are you saving the hook handle? The code above doesn't seem to be, you never put anything in the body of the KeyboardHookHandle setter. That means you're not unhooking when the forms closes and when you call the CallNextHookEx function you're passing an invalid hook handle in the first parameter. Also, I've tested this code with multiple forms and it only drops tab presses on the form with the acrobat control, that's what the GetActiveWindow() = Form_FooBar.hwnd in the keyboard hook is for. The way we use the adobe reader control is to open a popup form outside of access. Tabbing between controls on other forms works fine so the GetActiveWindow() check is working fine in our application. In addition to testing I performed, I deployed this fix to a few users this afternoon and didn't hear a peep out of them for the rest of the day so it's working for us.
---
Forgot to add that I've only tested this method of preventing the crash in access 2002 and 2003.
Dim m_hookHandle as Long
Public Property Get KeyboardHookHandle As Long
KeyboardHookHandle = m_hookHandle
End Property
Public Property Let KeyboardHookHandle(val as Long)
m_hookHandle = val
End Property
That should get you started. The reason I didn't include a body to those properties is because some folks handle things differently. Access, if you have never noticed, will reset all variables in the event of an unhandled error. In a locked down mdb, the code silently discards the error and continues to run only now with unexpected data stored in the global variables which obviously is a pretty bad thing. I've seen folks store global variables in hidden form fields and in tables. Just depends on the person and the scenario, so I just left those properties empty. This really goes outside of the scope of the problem here, a quick google search for 'access vba variables reset' should turn up plenty of details about what happens if you don't do proper error handling in your vba projects.
--
And as a result, if you don't unhook and call the next hook in the chain properly, wierd things can happen so it's important that you retain the handle returned when you set the keyboard hook until your hook has been released.
North America
Europe, Middle East and Africa
Asia Pacific